Error de Apple Mach-O Linker al compilar para dispositivo

Acabo de actualizarme a xcode 4.0 y ya no puedo implementarlo en iPhone, recibo un error de Apple Mach-O Linker, aunque todavía funciona para el 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

Aquí hay una solución permanente. La sobrescritura general de proyectos puede causar este problema. Pruebe este método.

-UPDATE - Error de Clang - Error de Mach-O Linker

En algunos casos, la ventana de registro de errores muestra el error .xctest, para solucionarlo

-> Seleccione su proyecto

-> Junto a esto (justo antes de la pestaña General) seleccione su archivo de prueba del proyecto desde el menú desplegable

-> Hay una opción (como ProjNameTests)

-> En la aplicación de host, seleccione su proyecto del menú desplegable solo si muestra personalizado

¡HECHO!

Método antiguo eliminado

Tuve el mismo problema y el problema fue que importé accidentalmente un archivo .m en lugar de .h en un archivo de implementación, espero que ayude

Acabo de encontrarme con el mismo problema.

La solución (para mí) = verifique sus marcos.

En mi caso, agregué clases relacionadas con CoreData sin "CoreData.framework". Agregarlo resolvió la queja de MACH_O.

Abra el archivo .xcworkspace no .xcodeproj. Repito abrir el archivo .xcworkspace. Todos tus errores desaparecerán.

Re: Problema como se describe en el título:

Por si alguien más se perdió lo obvio ...

Me encontré con este error después de instalar una nueva versión de Xcode4 y arrastrar los archivos existentes a un nuevo proyecto. No pude detectar que la casilla de verificación 'agregar a objetivos' se dejó sin marcar en el cuadro de diálogo 'Elegir opciones para agregar archivos:'. Corregir mi omisión en Targets> Build Fases> Compile Sources resolvió el problema.

Menú> Producto> Limpiar, esto es lo que lo hizo funcionar. No estoy seguro de todos los demás. Agregué una foto para mostrar.

Extraño error. Para mí, simplemente limpié y reinicié Xcode y el problema desapareció.

Solución: Configuración de compilación> Habilitar código de bits> No

Ninguna de estas respuestas me ayudó. Luego intenté reinstalar Cocoapods:

pod deintegrate

pod install

¡Problema resuelto!

El problema fue que en XCode 4, las dependencias no asumen la configuración de arquitectura del proyecto principal, como lo hicieron anteriormente en XCode 3. Tuve que pasar por todas mis dependencias configurándolas para la arquitectura correcta.

Tuve lo mismo y logré resolverlo.

En las preferencias de xcode , la pestaña de ubicación cambia el valor de la ubicación de compilación a " Place build products in locations specified by targets".

Luché con esto por un tiempo, y en mi caso terminó siendo la Configuración de compilación en Rutas de búsqueda llamada FRAMEWORK_SEARCH_PATHS. Me ayudó que seleccioné el botón "Niveles", que parecía comparar mi proyecto, objetivo y configuración "Resuelto". Vi que mi configuración de destino de alguna manera anuló el valor predeterminado de "$ (heredado)", y el valor anulado fue lo que XCode "resolvió". Cuando eliminé la anulación, que en este caso especificó el 3.2 sdk, los errores del enlazador desaparecieron, al igual que algunas advertencias aparecidas recientemente sobre cualquier clase donde llamé a los métodos posteriores a 4.0.

Acerca de esas advertencias: nunca las vi antes de agregar el marco MessageUI para un cambio reciente. Sospecho, pero no estoy seguro, que cuando agregué ese marco, XCode intentó hacer algo inteligente al agregar esa anulación a mi objetivo. No lo hice explícitamente en ningún momento. Las advertencias fueron, por ejemplo, sobre el método URLByAppendingPathComponent de NSURL, que no apareció hasta sdk 4.0. Antes de agregar el marco de MessageUI, nunca recibí esa advertencia. Y como eliminé la anulación, ya no las obtengo.

Tuve este problema y la importación lo QuartzCoresolucionó.

Cambiar "Construir arquitecturas activas solamente" a Sí en CordovaLib.xcodeproj -> La configuración de compilación me ayudó. anteriormente la aplicación se estaba ejecutando en el simulador, pero no en el dispositivo.

Es posible que deba actualizar la configuración de compilación.

Verifique la versión de destino de iOS y las arquitecturas del procesador, ya que es posible que no tenga los SDK antiguos con XCode 4.

Puede ver «Falta el SDK» en la configuración de compilación. Cambie eso a lo que corresponda.

Tuve el mismo problema: simplemente eliminé accidentalmente un archivo .m, mientras que .h estaba en el proyecto. El problema desapareció cuando restauré el archivo .m.

Verifique para asegurarse de que no tiene una ruta de búsqueda de marco específica especificada. si va a la información en el destino y simplemente elimina las entradas de la ruta de búsqueda del marco, debería usar los valores predeterminados para la versión de implementación especificada.

Solo trato de crear un category classarchivo y tengo este problema extraño ... y finalmente ...

Manera incorrecta de crear una clase de categoría que causa el problema:

New File-> Cocoa Touch-> Objective-C class, luego modifiqué el nombre de los archivos a Categoría Clase como nombre .. (es decir , OriginalClass_CategoryName.h/ma OriginalClass+CategoryName.h/m, y también modifiqué el contenido del archivo).

Justo aquí:

New File-> Cocoa Touch-> Objective-C category, y generará automáticamente los archivos ( OriginalClass+CategoryName.h/m).

¡Oh, qué estúpido soy!

Si está utilizando CoreData y utiliza XCode para generar subclases NSManagedObject para sus entidades, asegúrese de generar solo una para cada entidad.

Mi problema fue que generó múltiples subclases de NSManagedObject para la misma entidad (y las colocó en diferentes carpetas).

Simplemente los eliminé y regeneré las subclases NSManagedObject.

Para agregar a la lista de cosas raras que solucionaron este problema ...

Tuve algunas variables constantes CGFloat en un archivo de encabezado global así

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

En el momento en que los quité, todo estuvo bien :)

Tuve exactamente el mismo problema solo porque tenía dos constantes iguales en diferentes clases. También puede tener este problema si importa un archivo .m, no un archivo .h

No estoy seguro de si está relacionado, pero al ver que está ejecutando unas tres20 bibliotecas, puede consultar esta publicación en su sitio web: http://three20.info/article/2011-03-10-Xcode4-Support

Tuve el mismo problema y lo resolví. En mi caso, la configuración de "arquitecturas" causó el problema. En mi archivo de proyecto, pestaña Configuración de compilación, las arquitecturas se configuraron en armv6. Lo cambié a Estándar (armv7), limpio y compilado. Entonces funcionó!

En mi caso, el problema era tener diferentes arquitecturas especificadas bajo diferentes objetivos. Estaba creando mi objetivo de aplicación con armv6, armv7 y cocos2d con Standard (amrv7). Vaya a la configuración de construcción y asegúrese de que sus arquitecturas estén de acuerdo con todos los objetivos.

¡Resolví este problema demasiado raro!

Vaya a Destino > Fases de construcción > Enlace binario con bibliotecas :

¡Elimine todos sus marcos y agréguelos nuevamente!

Espero que funcione para ti !

Para lenguaje rápido ...

Recibo este error "ld: archivo demasiado pequeño (longitud = 0) ...."

En mi caso, simplemente limpio el proyecto y luego lo reconstruyo.

Pasos:-

1) Ir al proyecto -> Limpiar

2) Ir a Proyecto -> Construir

Espero que esto ayude..

Esto hizo un truco para mí:

Ir

1) Productos> limpiar

2) Windows> Proyectos

3) Seleccione su proyecto y haga clic en " Eliminar " Datos derivados

4) Productos> Construir

Una posibilidad: active "Eliminación de código muerto" en la configuración de compilación de Xcode 4.

Otra posibilidad: puede ser que haya cambiado a usar LLVM para algún marco que anteriormente usaba GCC. Regresar a GCC (o LLVM GCC) puede eliminar esas advertencias.

Definí erróneamente una nueva constante con el mismo nombre que una constante existente en un archivo diferente y me causó este error al usar xCode 4.3.1. xCode no se quejó pero al compilador no le gusta.

Pude corregir este error editando "Rutas de búsqueda de la biblioteca"

En primer lugar, surgió porque había movido un par de carpetas, y eso terminó dando a mi configuración de compilación dos rutas de búsqueda diferentes porque se agregan automáticamente a su configuración de compilación cuando vincula una biblioteca / marco, pero no son Siempre eliminado.

Entonces, si mueve una biblioteca / marco vinculado a un directorio diferente y lo vuelve a vincular, deberá editar manualmente la ruta de búsqueda.

Es posible que pueda esquivar esto eliminando la biblioteca / marco antes de moverlo, pero no lo he probado.