“bad codegen, pointer diff” linker error with Xcod

问题:

Recompiling a C++ iPhone app with Xcode 4 I get this nasty linker error:

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

Anyone know what it means? How to make it go away would be nice too of course :)

The app compiled & linked without error in Xcode 3.

Edit: the solution is to set Symbols Hidden By Default to Yes in all the build settings of all targets in the project. Still none the wiser what the actual problem was.

回答1:

The solution is to set Symbols Hidden By Default to Yes in all the build settings of all targets in the project. Still none the wiser what the actual problem was.

回答2:

I had the same problem and also ended up adjusting the visibility settings. However, I was nervous just fiddling with symbol visibility and not understanding the problem, so I did a little more investigation.

If, like me, you're using Pete Goodliffe's script/package to build boost as a framework, the script sets default visibility to hidden (== yes). The visibility options change how symbols are marked by the compiler (default, hidden, internal). That information is used by the linker when making shared object elfs (shared libraries). It shouldn't apply here, so I suspect that this is a linker bug. Inside the boost library you have a weak symbol marked as hidden, and then in your project/another library, the same symbol marked as default. The linker is confused?

As for XCode 3 vs. 4, perhaps the default in 3 was to hide symbols?

In any case, changing default visibility to hidden should really have no effect with only static libs involved, so I feel a lot safer taking this route.

I've posted a few more details in a blog entry for those interested.

回答3:

I ran into this problem while trying to include the boost libraries one of my projects. After finding this post, setting Symbols Hidden By Default to Yes also solved this issue for me. And I also had to make the same setting in each of the dependent projects to completely get rid of the error.

Just FYI - This only happened on my targets that were using the clang++ stack. GCC and LLVM+GCC targets do not seem to be affected.

回答4:

Basically any symbols in a library you link to & your own code, need to use the same visibility level, i.e. if all the symbols in a library you include are hidden you need make sure the include files referencing the symbols in your project don't try and set it to visible. the safest way to do this is to have a constant level of default visibility across your project, for me it only became a problem with optimisations on.

回答5:

Perhaps you are using a library that has hidden symbol information. If a symbol has not been exported from your library, and you attempt to use it externally, it results in a similar linker error. The correct solution would seem to be to find a way to make that symbol "visible" to the outside world via GCC macro definitions and/or modify the library itself to make sure that that particular symbol is truly "hidden" from the outside world --i.e. it isn't something that is ever used or exposed in a header file.

However, proceed with caution: according to Apple documentation, you should not hide some symbol information for a number of reasons; this one listed below seems to be the most alarming of the bunch:

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.

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

Thus, if you want to catch an exception from the library you're linking against, hiding symbol information appears to be a bad choice. The correct solution would be to unhide the symbols of whatever library you're linking to. This can either be done by omitting the following GCC compiler flags:

-fvisibility=hidden --fvisibility-inlines-hidden

(the default visibility should be sufficient), or there are also compiler pragmas that allow you to do this. See: http://gcc.gnu.org/wiki/Visibility