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

-
P.S.
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 (http://developer.apple.com/devforums/). 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.
from http://gcc.gnu.org/onlinedocs/gcc-4.5.3/gcc/Code-Gen-Options.html#index-fvisibility-2129

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.

Comments

Post a Comment

Popular posts from this blog

Hardcoding Data Like Images and Sounds into HTML or CSS

-
Image
Do you know Data URI scheme ? With this, you can hardcode virtually any kind of digital information media into a document. Okay, "virtually any kind of" was a little bit unreasonable; "almost all browser-supported" is appropriate, such as images, sounds and movies. The format below defines a data URI (we need to use safe URL characters; see also " Recommendations for Delimiting URI in Context " for delimiting a long URI): data:[<MIME-type>][;charset=<encoding>][;base64],<data> URL is used to locate various resources, for example web browsers can't live without these URLs, and URI is a conceptual superset of URL. And protocols defined by data URI scheme provide a standardized way to hardcode certain data, such as JPEG, PNG, MP3, Ogg etc. With this scheme we can hardcode data inside virtually all kinds of source code from interpreted languages like HTML, XML, CSS, JS, Ruby, PHP or even from compiled languages like C, C++,
« Read More »

Make It Work: Global .gitattributes

-
Image
Git is the vanguard of distributed VCSs, and as a matter of course, it provide a way to perform diff or merge on certain files while intermediately treating them as documents of a certain other format. By reflecting appropriate changes to configuration and attributes of git as described in " Git - Git Attributes ," you can set up this intermediate conversion for files of your choice while in diff or merge process. This is best described with an example. Say, there exists a file format called "property list" (hereinafter plist) in Mac, and it can come in 3 forms: XML, binary or JSON (it's not exactly JSON, but is similar to it). To perform diff or merge on files of this type in a consistent way, use command plutil  provided by Mac OS X (or an open-source, GPL-licensed alternative libplist ). Then take the following 2 steps.
« Read More »

Xcode: Easy Shared & Static Lib Management and Linking

-
Image
In Xcode, you can add existing frameworks (binary shared/static libraries or Apple's packaged framework) to a target in your project by choosing from the framework list or drag'n'drop from Finder. Several libraries under "Frameworks" group (e.g. libBusted.a) Benefit of doing this is obvious: you can manage and see what libraries your program is linked to. However, after doing that, I noticed one thing. Xcode does not link shared/static libraries in a simple way like: gcc -o qux libfoo.dylib libbar.a buz.o Instead, when libraries are going to be added, Xcode obtains paths to the directories containing these libraries, and appends these to the build setting "Library Search Path" of the target. So that the actual linking looks like: gcc -L/path/to/foobar -o qux -lfoo libbar.a buz.o Compared to the former, even though orthodox, linking in the latter is indirect. I like the former method because it's simple and error-free even though it somewh
« Read More »