"bad codegen, pointer diff" linker error with Xcode 4

Question

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.

Answer 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.

Answer 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.

Answer 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.