Linking issues with OS X 10.10

Question

I'm trying to compile some code in OSX 10.10 using the latest Xcode cmd line tools. Compilation works, but linking is a nightmare. First, I get an error that a symbol is multiply defined. This error is correct, but the definitions are identical and in 3rd-party libraries that I don't control. I can not figure out how to force the linker to ignore this issue. One important note is that the same code compiles, links and runs flawlessly on my Ubuntu box, under both clang and gcc. This linker issue is only under OS X. The libraries are static.

The second issue I encounter is even stranger. If I remove some (necessary) functionality just so I can compile and link the program, I get the following fun message when I run it: "dyld: Symbol not found: __ZNSt12future_errorD1Ev". The hell is that, and how do I fix it? Google was unhelpful on that front.

Answer 1

OK, so I've resolved this issues to the best of my understanding. Here's what I learned. First, the static linking issue does not seem possible to resolve on OSX using Apple's "special" version of Clang. Short of editing the source code of the library, there seems to be no way to tell the compiler to ignore duplicate symbol definitions. There used to be such options (e.g. -m), but they've all been deprecated for a while. Thus, to address this issue, I had to make at least one of the libraries dynamic.

The second issue was due to the fact that one of the libraries against which I was trying to link was, somehow, compiled against libstdc++. However, Apple's clang wants to compile everything against libc++ by default. Thus, the problem was one of compatibility between the two libraries --- std::future_error had a different mangled name in both and at runtime (when I was using libc++) the symbol from libstdc++ couldn't be found. The proper solution for this problem (which I bit the bullet and did) was to re-compile any library in this project using libc++, as the the two implementations of the standard library are not, in general, compatible.

Anyway, I hope this ends up being useful to someone else. I find it incredibly frustrating that Apple has to be different enough to ensure that builds that work perfectly well under multiple compilers under Linux, break horribly in their OS under their custom version of clang.