Transition Mayhem: Xcode 4 (and Symbol Visibility Side Note)

To guys here for "illegal text reloc to vtable" or "bad codegen" of Xcode 4

If you enrolled one of Apple Developer Programs, preferably Mac Developer Program, you should visit the exclusive web forum at Apple Developer Connection ( I found a thread where one of OGRE library developers mentioning he found info about this "illegal text reloc to vtable" or "bad codegen" things at that forum. Something like Apple tightened up their policy on how to resolve symbols in Xcode 4. Unfortunately, I didn't enroll any of Apple Developer Programs, and don't know the detail.

I like Xcode because this is the first IDE I got used to, but I don't like Xcode 4 not working as I want.

Let me cut to the point, I have a problem compiling my project in Xcode 4. Compiling goes well in Xcode 3, but in Xcode 4, illegal text reloc to vtable or bad codegen things comes up to slap the back of my head every time. Wow, annoying. After some googling, I found people saying that turning on the build settings "Symbols Hidden by Default" of the build target solved the problem.

But, I don't like that solution, considering how casually it was mentioned. Here, read this first. It's from a GCC man page:
Be aware that headers from outside your project, in particular system headers and headers from any other library you use, may not be expecting to be compiled with visibility other than the default. You may need to explicitly say `#pragma GCC visibility push(default)' before including any such headers.

The build setting is a synonym of the compiler option -fvisibility=hidden, and that compiler option set the default symbol visibility as "hidden," meaning the symbols are meant to be used only internally, not part of API. So, this option is meant for fine tuning your shared objects. And don't forget, the result of this option is intrusive.

How intrusive: the effect can be applied even to symbols beyond #include directives, means it tries to mark the symbols of standard libraries or third party libraries included as "hidden." That's not good, because those symbols were exported already in header file side and shared object side at their compile time and the same was expected in your side (that's the nature of shared objects), but this compiler option is trying to deny it and take those symbols as hidden. It may succeed changing default visibility in header files, but not in shared objects. If your compiler complains about different visibility of certain symbols, I guess that means this.

Unbeknownst to or taken granted by many, even their developers, some libraries rely on "default" public visibility. With this option -fvisibility=hidden set up, it's not the same world anymore: symbols intended to be exported (globally accessible) from libraries with no explicit visibility direction end up being marked as "not to be exported." One can sandwich #include directives with #pragma GCC visibility push(default) and #pragma GCC visibility pop to temporarily set the default visibility as "default," but it will be some work to reflect this change to all the source code.

Some good, intense googling might explain not just a solution but the cause for this Xcode 4 problem.

But… phew, symbol visibility is a headache, I'll turn off every build setting changing the default visibility and rebuild the project including dependencies, and switch back to Xcode 3 for the time being.
Tiresome, really tiresome.


Popular posts from this blog

Hardcoding Data Like Images and Sounds into HTML or CSS

DDS for GIMP (Mountain Lion, Native, no X11 GUI)

Make It Work: Global .gitattributes