Erro do Apple Mach-O Linker ao compilar para o dispositivo

Acabei de atualizar para o xcode 4.0 e não consigo mais implantar no iPhone, recebo um erro do Apple Mach-O Linker, mas ainda funciona para o simulador.

    Ld /Users/yveswheeler/Library/Developer/Xcode/DerivedData/iParcel-fkeqjcjcbbhjwhdssjptkdxzzzxh/Build/Intermediates/iParcel.build/Debug-iphoneos/iParcel.build/Objects-normal/armv7/iParcel normal armv7
    cd /Users/yveswheeler/iParcel
    setenv IPHONEOS_DEPLOYMENT_TARGET 3.2
    setenv PATH "/Developer/Platforms/iPhoneOS.platform/Developer/usr/bin:/Developer/usr/bin:/usr/bin:/bin:/usr/sbin:/sbin"
    /Developer/Platforms/iPhoneOS.platform/Developer/usr/bin/g++-4.2 -arch armv7 -isysroot /Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS4.3.sdk -L/Users/yveswheeler/Library/Developer/Xcode/DerivedData/iParcel-fkeqjcjcbbhjwhdssjptkdxzzzxh/Build/Products/Debug-iphoneos -F/Users/yveswheeler/Library/Developer/Xcode/DerivedData/iParcel-fkeqjcjcbbhjwhdssjptkdxzzzxh/Build/Products/Debug-iphoneos -filelist /Users/yveswheeler/Library/Developer/Xcode/DerivedData/iParcel-fkeqjcjcbbhjwhdssjptkdxzzzxh/Build/Intermediates/iParcel.build/Debug-iphoneos/iParcel.build/Objects-normal/armv7/iParcel.LinkFileList -dead_strip -all_load -ObjC -lxml2 -miphoneos-version-min=3.2 -framework UIKit -framework CoreGraphics -framework QuartzCore /Users/yveswheeler/Library/Developer/Xcode/DerivedData/iParcel-fkeqjcjcbbhjwhdssjptkdxzzzxh/Build/Products/Debug-iphoneos/libThree20.a /Users/yveswheeler/Library/Developer/Xcode/DerivedData/iParcel-fkeqjcjcbbhjwhdssjptkdxzzzxh/Build/Products/Debug-iphoneos/libThree20Core.a /Users/yveswheeler/Library/Developer/Xcode/DerivedData/iParcel-fkeqjcjcbbhjwhdssjptkdxzzzxh/Build/Products/Debug-iphoneos/libThree20Network.a /Users/yveswheeler/Library/Developer/Xcode/DerivedData/iParcel-fkeqjcjcbbhjwhdssjptkdxzzzxh/Build/Products/Debug-iphoneos/libThree20Style.a /Users/yveswheeler/Library/Developer/Xcode/DerivedData/iParcel-fkeqjcjcbbhjwhdssjptkdxzzzxh/Build/Products/Debug-iphoneos/libThree20UI.a /Users/yveswheeler/Library/Developer/Xcode/DerivedData/iParcel-fkeqjcjcbbhjwhdssjptkdxzzzxh/Build/Products/Debug-iphoneos/libThree20UICommon.a /Users/yveswheeler/Library/Developer/Xcode/DerivedData/iParcel-fkeqjcjcbbhjwhdssjptkdxzzzxh/Build/Products/Debug-iphoneos/libThree20UINavigator.a -framework AddressBook -lz.1.2.3 -framework Foundation -framework CFNetwork -framework MobileCoreServices -framework SystemConfiguration -framework MessageUI -framework AudioToolbox -o /Users/yveswheeler/Library/Developer/Xcode/DerivedData/iParcel-fkeqjcjcbbhjwhdssjptkdxzzzxh/Build/Intermediates/iParcel.build/Debug-iphoneos/iParcel.build/Objects-normal/armv7/iParcel

arm-apple-darwin10-g++-4.2.1: /Users/yveswheeler/Library/Developer/Xcode/DerivedData/iParcel-fkeqjcjcbbhjwhdssjptkdxzzzxh/Build/Products/Debug-iphoneos/libThree20.a: No such file or directory
arm-apple-darwin10-g++-4.2.1: /Users/yveswheeler/Library/Developer/Xcode/DerivedData/iParcel-fkeqjcjcbbhjwhdssjptkdxzzzxh/Build/Products/Debug-iphoneos/libThree20Core.a: No such file or directory
arm-apple-darwin10-g++-4.2.1: /Users/yveswheeler/Library/Developer/Xcode/DerivedData/iParcel-fkeqjcjcbbhjwhdssjptkdxzzzxh/Build/Products/Debug-iphoneos/libThree20Network.a: No such file or directory
arm-apple-darwin10-g++-4.2.1: /Users/yveswheeler/Library/Developer/Xcode/DerivedData/iParcel-fkeqjcjcbbhjwhdssjptkdxzzzxh/Build/Products/Debug-iphoneos/libThree20Style.a: No such file or directory
arm-apple-darwin10-g++-4.2.1: /Users/yveswheeler/Library/Developer/Xcode/DerivedData/iParcel-fkeqjcjcbbhjwhdssjptkdxzzzxh/Build/Products/Debug-iphoneos/libThree20UI.a: No such file or directory
arm-apple-darwin10-g++-4.2.1: /Users/yveswheeler/Library/Developer/Xcode/DerivedData/iParcel-fkeqjcjcbbhjwhdssjptkdxzzzxh/Build/Products/Debug-iphoneos/libThree20UICommon.a: No such file or directory
arm-apple-darwin10-g++-4.2.1: /Users/yveswheeler/Library/Developer/Xcode/DerivedData/iParcel-fkeqjcjcbbhjwhdssjptkdxzzzxh/Build/Products/Debug-iphoneos/libThree20UINavigator.a: No such file or directory
Command /Developer/Platforms/iPhoneOS.platform/Developer/usr/bin/g++-4.2 failed with exit code 1

Aqui está a solução permanente. Geralmente, o projeto de substituição pode causar esse problema. Tente este método.

-UPDATE - Clang error - Erro do Mach-O Linker

Em alguns casos, a janela do log de erros exibindo erro .xctest, para corrigi-lo

-> Selecione seu projeto

-> Ao lado disso (logo antes da guia Geral), selecione o arquivo projectTest no menu suspenso

-> Existe uma opção (como ProjNameTests)

-> No Aplicativo Host, selecione seu projeto no menu suspenso apenas se ele mostrar

FEITO!

Método antigo excluído

Eu tive o mesmo problema e o problema foi que eu acidentalmente importei um arquivo .m em vez de .h em um arquivo de implementação - espero que ajude

Acabei de encontrar o mesmo problema.

A solução (para mim) = verifique suas estruturas.

No meu caso, eu adicionei classes relacionadas ao CoreData sem "CoreData.framework". Adicioná-lo resolveu a reclamação do MACH_O.

abra o arquivo .xcworkspace e não .xcodeproj. Repito o arquivo .xcworkspace aberto. Todos os seus erros desaparecem.

Re: Problema como descrito no título:

Apenas no caso de alguém perder o óbvio ...

Me deparei com esse erro depois de instalar uma nova versão do Xcode4 e arrastar os arquivos existentes para um novo projeto. Não consegui identificar que a caixa de seleção 'adicionar aos destinos' foi deixada desmarcada na caixa de diálogo 'Escolha opções para adicionar arquivos:'. Corrigir minha omissão em Destinos> Criar fases> Compilar fontes resolveu o problema.

Menu> Produto> Limpo, foi isso que fez funcionar. Eu não tenho certeza sobre todos os outros. Eu adicionei foto para mostrar.

Erro bizarro. Para mim, limpei e reiniciei o Xcode e o problema foi resolvido.

Correção: Configurações de compilação> Ativar código de bits> Não

Nenhuma dessas respostas me ajudou. Então eu tentei reinstalar o Cocoapods:

pod deintegrate

pod install

Problema resolvido!

O problema era que no XCode 4, as dependências não assumem as configurações de arquitetura do projeto principal, como fizeram anteriormente no XCode 3. Eu tive que passar por todas as minhas dependências, definindo-as para a arquitetura correta.

Eu tinha o mesmo e consegui resolvê-lo.

Nas preferências do xcode , a guia local altera o valor em local da construção para " Place build products in locations specified by targets".

Eu lutei com isso por um tempo e, no meu caso, acabou sendo a Configuração de Compilação em Caminhos de Pesquisa chamada FRAMEWORK_SEARCH_PATHS. Ajudou a seleção do botão "Níveis", que parecia comparar meu projeto, destino e configurações "Resolvidas". Vi que minha configuração de destino substituiu de alguma forma o padrão "$ (herdado)", e o valor substituído foi o que o XCode "resolveu" a configuração. Quando removi a substituição, que neste caso especificou o 3,2 sdk, os erros do vinculador desapareceram - assim como alguns avisos recentes apareceram sobre qualquer classe em que chamei métodos pós-4.0.

Sobre esses avisos - nunca os vi antes de adicionar a estrutura do MessageUI para uma alteração recente. Suspeito, mas não sei ao certo, que quando adicionei essa estrutura, o XCode tentou fazer algo inteligente, adicionando essa substituição ao meu destino. Eu não fiz isso explicitamente em nenhum momento. Os avisos foram, por exemplo, sobre o método URLByAppendingPathComponent de NSURL, que não apareceu até o sdk 4.0. Antes de adicionar a estrutura MessageUI, nunca recebi esse aviso. E desde que removi a substituição, não as recebo mais.

Eu tive esse problema e a importação o QuartzCorecorrigiu.

Alterar "Construir somente arquiteturas ativas" para Sim em CordovaLib.xcodeproj -> Configurações de compilação fez o truque para mim. anteriormente, o aplicativo estava sendo executado no simulador, mas não no dispositivo.

Pode ser necessário atualizar suas configurações de compilação.

Verifique a versão de destino do iOS e as arquiteturas do processador, pois você pode não ter os SDKs antigos com o XCode 4.

Você pode ver "SDK ausente" nas configurações de compilação. Mude isso para o que for aplicável.

Eu tive o mesmo problema: excluí acidentalmente um arquivo .m, enquanto .h estava no projeto. O problema desapareceu quando eu restaurei o arquivo .m.

Verifique se você não possui um caminho de pesquisa de estrutura específico especificado. se você acessar as informações no destino e apenas remover as entradas do caminho de pesquisa da estrutura, ele deverá usar os padrões da versão de implantação especificada.

Eu apenas tento criar um category classarquivo e consegui esse problema estranho ... e finalmente ....

Maneira errada de criar uma classe de categoria que causa o problema:

New File-> Cocoa Touch-> Objective-C class, modifiquei o nome dos arquivos para Categoria de categoria como o nome .. (ou seja , OriginalClass_CategoryName.h/mpara OriginalClass+CategoryName.h/m, e também modifiquei o conteúdo do arquivo).

Caminho certo aqui:

New File-> Cocoa Touch-> Objective-C category, e ele gera automaticamente arquivos ( OriginalClass+CategoryName.h/m).

Oh, como eu sou estúpido!

Se você estiver usando CoreData e usar XCode para gerar subclasses NSManagedObject para suas entidades, certifique-se de gerar apenas uma para cada entidade.

Meu problema foi que ele gerou várias subclasses NSManagedObject para a mesma entidade (e as colocou em pastas diferentes).

Acabei de excluir todos eles e regenerar as subclasses NSManagedObject.

Para adicionar à lista de coisas estranhas que corrigiram esse problema ...

Eu tinha algumas variáveis ​​const CGFloat em um arquivo de cabeçalho global como esse

const NSInteger  globalInteger1 = 2;
const NSInteger  globalInteger2 = 3;

No momento em que os removi, estava tudo bem :)

Eu tive exatamente o mesmo problema só porque tinha duas mesmas constantes em classes diferentes. Você também pode ter esse problema se importar arquivo .m e não arquivo .h

Não tenho certeza se está relacionado, mas, como você está executando algumas três20 bibliotecas, verifique esta publicação no site: http://three20.info/article/2011-03-10-Xcode4-Support

Eu tive o mesmo problema e resolvi-o. No meu caso, a configuração de "arquiteturas" causou o problema. No meu arquivo de projeto, na guia Configurações de compilação, as arquiteturas foram definidas para armv6. Eu mudei para Standard (armv7), limpe e construa. Então funcionou!

No meu caso, o problema era ter diferentes arquiteturas especificadas sob diferentes destinos. Eu estava construindo meu destino de aplicativo com armv6, armv7 e cocos2d com Standard (amrv7). Entre nas configurações de compilação e verifique se suas arquiteturas concordam com todos os destinos.

Eu resolvi esse problema muito estranho!

Vá para Target > Build Fhases > Link Binary com bibliotecas :

Remova todas as suas estruturas e adicione-as novamente!

Espero que funcione para você !

Para o idioma Swift ...

Estou recebendo este erro "ld: arquivo muito pequeno (comprimento = 0) ...."

No meu caso, apenas limpo o projeto e depois o reconstruo ..

Passos:-

1) goto Projeto -> Limpo

2) vá para Projeto -> Compilar

Espero que isto ajude..

Isso fez um truque para mim:

Vamos para

1) Produtos> limpos

2) Windows> Projetos

3) Selecione seu projeto e clique em " Excluir " dados derivados

4) Produtos> Construção

Uma possibilidade: ative "Stript code morto" nas configurações de compilação do Xcode 4.

Outra possibilidade: pode ser que você tenha mudado para o LLVM para alguma estrutura que estava usando o GCC anteriormente. Voltar para o GCC (ou LLVM GCC) pode se livrar desses avisos.

Defini por engano uma nova constante com o mesmo nome que uma constante existente em um arquivo diferente e isso causou esse erro para mim usando o xCode 4.3.1. O xCode não reclamou, mas o compilador não gostou.

Consegui corrigir esse erro editando "Caminhos de pesquisa da biblioteca"

Ele surgiu em primeiro lugar porque eu havia movido algumas pastas e isso acabou dando às minhas configurações de compilação dois caminhos de pesquisa diferentes, porque eles são adicionados automaticamente às suas configurações de compilação quando você vincula uma biblioteca / estrutura, mas elas não são sempre removido.

Portanto, se você mover uma biblioteca / estrutura vinculada para um diretório diferente e o vincular novamente, terá que editar manualmente o caminho da pesquisa.

Você pode evitar isso removendo a biblioteca / estrutura antes de movê-la, mas eu não testei isso.