error "malo codegen, puntero del diff" enlazador con Xcode 4

Question

Volver a compilar una aplicación de iPhone C++ con Xcode 4 me sale este error desagradable enlazador:

ld: bad codegen, pointer diff in __static_initialization_and_destruction_0(int, int) 
to global weak symbol vmml::Vector2<float>::ZERO for architecture armv6 

Alguien sabe lo que significa? Cómo hacer que desaparezca sería bueno también, por supuesto :)

La aplicación compilada & vinculado sin error en Xcode 3.

Editar: la solución es establecer Símbolos ocultos por defecto a Sí en todas las configuraciones de compilación de todos los objetivos del proyecto. Todavía nadie es más sabio de lo que era el problema real.

Answer 1

La solución es establecer Symbols Hidden By Default en Sí en todas las configuraciones de compilación de todos los destinos del proyecto. Todavía nadie es más sabio de lo que era el problema real.

Answer 2

Me encontré con este problema al tratar de incluir las bibliotecas de impulso uno de mis proyectos. Después de encontrar esta publicación, configurar Symbols Hidden By Default en Yes también resolvió este problema para mí. Y también tuve que hacer la misma configuración en cada uno de los proyectos dependientes para eliminar por completo el error.

Solo FYI - Esto solo sucedió en mis objetivos que usaban la pila clang ++. Los objetivos GCC y LLVM + GCC no parecen verse afectados.

Answer 3

Tuve el mismo problema y también terminé ajustando la configuración de visibilidad. Sin embargo, estaba nervioso solo jugando con la visibilidad de símbolos y no entendiendo el problema, así que investigué un poco más.

Si, como yo, está utilizando la secuencia de comandos/paquete de Pete Goodliffe para crear un impulso como marco, la secuencia de comandos establece la visibilidad predeterminada como oculta (== sí). Las opciones de visibilidad cambian la forma en que el compilador marca los símbolos (predeterminado, oculto, interno). Esa información es utilizada por el vinculador al hacer elfs de objetos compartidos (bibliotecas compartidas). No debería aplicarse aquí, así que sospecho que esto es un error de enlazador. Dentro de la biblioteca de impulso, tiene un símbolo débil marcado como oculto, y luego en su proyecto/otra biblioteca, el mismo símbolo marcado como predeterminado. El enlazador está confundido?

En cuanto a XCode 3 vs. 4, ¿quizás el valor predeterminado en 3 era ocultar símbolos?

En cualquier caso, cambiar la visibilidad predeterminada a oculta no debería tener ningún efecto con solo libs estáticos involucrados, por lo que me siento mucho más seguro al tomar esta ruta.

He publicado algunos más detalles en un blog entry para los interesados.

Answer 4

Básicamente cualquier símbolo en una biblioteca que vincule a & su propio código, necesita usar el mismo nivel de visibilidad, es decir, si todos los símbolos de una biblioteca que incluye están ocultos, asegúrese de que los archivos de inclusión hagan referencia a los símbolos en su proyecto no intente y establézcalo en visible. La forma más segura de hacerlo es tener un nivel constante de visibilidad predeterminada en todo el proyecto, para mí solo se convirtió en un problema con las optimizaciones.

Answer 5

Quizás esté utilizando una biblioteca que tiene información de símbolos oculta. Si un símbolo no se ha exportado desde su biblioteca, e intenta utilizarlo externamente, se produce un error de vinculador similar.La solución correcta sería encontrar la manera de hacer que ese símbolo sea "visible" para el mundo exterior a través de las definiciones de macro de GCC y/o modificar la biblioteca para asegurarse de que ese símbolo en particular esté realmente "oculto" del mundo exterior. -es decir no es algo que se use o exhiba en un archivo de encabezado.

Sin embargo, proceda con precaución: de acuerdo con la documentación de Apple, no debe ocultar la información de símbolos por varias razones; éste se enumeran a continuación parece ser el más alarmante del grupo:

If your symbol uses runtime type identification (RTTI) information, exceptions, or dynamic casts for an object that is defined in another library, your symbol must be visible if it expects to handle requests initiated by the other library. For example, if you define a catch handler for a type in the C++ standard library, and you want to catch exceptions of that type thrown by the C++ standard library, you must make sure that your typeinfo object is visible.

Fuente: http://developer.apple.com/library/mac/#documentation/DeveloperTools/Conceptual/CppRuntimeEnv/Articles/SymbolVisibility.html

Por lo tanto, si se desea capturar una excepción de la biblioteca va a asociar contra, ocultando aparece información de símbolos ser una mala elección La solución correcta sería para mostrar los símbolos de la biblioteca a la que está enlazando. Esto puede hacerse ya sea por omisión las siguientes opciones del compilador GCC:

-fvisibility=hidden --fvisibility-inlines-hidden

(la visibilidad por defecto debería ser suficiente), o también hay pragmas del compilador que le permiten hacer esto. Ver: http://gcc.gnu.org/wiki/Visibility