5

Under Mac OS X 10.6 I am building a C++ shared library which links to boost 1.46. I am using the command line tools installed with Xcode 4.0.

The 64-bit build works fine. When building for 32-bit, I get the following error message upon linking: 

ld: bad codegen, pointer diff in boost::detail::sp_counted_base::sp_counted_base()to global weak symbol vtable for boost::detail::sp_counted_basefor architecture i386

The only workaround I found is to use g++-4.0 for the 32-bit build. The other compilers I tried (g++-4.2, llvm-g++-4.2 and clang++) all produce the error above.

sakra
  • 62,199
  • 16
  • 168
  • 151

5 Answers5

5

The issue is most likely that you're statically linking together two libraries with different values for the default visibility (-fvisibility). You can either make sure to use the same visibility flags for both boost and your project, or use an explicit export symbol file.

servn
  • 3,049
  • 14
  • 8
2

you're probably linking a library built with gcc 4.0, which has incompatible ABI with gcc 4.2 and clang. You should rebuild all libraries used with gcc4.2 or clang, using same compiler options as your main application (particular note to the option "C++ standard library type" aka STANDARD_C_PLUS_PLUS_LIBRARY_TYPE which should be set to "static" or "dynamic" consistently in all libraries). Another useful option is "symbols hidden by default" but beware that enabling that would hide nasty bugs that would rise if you pass C++ objects between libraries compiled with different options/compilers.

pqnet
  • 6,070
  • 1
  • 30
  • 51
  • Boost was built with gcc 4.2 as a universal binary with dynamic libstdc++. Except for the architecture I am using the same settings for 32 and 64 bit. Should't these errors also occur in the 64-bit build then? – sakra May 30 '11 at 18:48
  • 1
    i could guess two reason: either there's an option which makes your code incompatible that is not supported for 64-bit architecture, or the 64-bit ABI doesn't break compatibility for that. From the look of it however is not necessarily boost itself which is conflicting with your code, it could be another library using boost (and thus compiling boost headers with different options): are you linking some other binary libraries other than boost? – pqnet May 31 '11 at 08:47
  • Boost has a bunch of variants of the sp_counted_base class for different architectures... they are doing some CPU specific stuff to do atomic operations, so it's quite possible that there's some issue on one architecture that doesn't show up in the other. FWIW, someone in our lab got this same error after trying to fix some other visibility errors, we did a clean build of the client code (Ogre3D) and then, this went away. *shrug* – Ethan Jul 15 '11 at 18:27
2

For information: In XCode, visibility is set in Code Generation > Inline Method Hidden and Symbols Hidden by default

Setting those to NO fixes this issue.

This corresponds in effet to gcc -fvisibility-inlines-hidden and -fvisibility flags. You may uses those to only adjust your code's setting instead of messing with boost.

Alain Vitry
  • 158
  • 2
  • 11
1

As said here:

If boost is included by multiple projects, each project must have the same values for

 Symbols Hidden by Default
 Inline Methods Hidden
Community
  • 1
  • 1
cyrilchampier
  • 2,207
  • 1
  • 25
  • 39
1

The problem seems to be fixed in the linker that is installed with XCode 4.2. Upon linking I now get a warning instead of the error message:

ld: warning: direct access in __ZN5boost6detail15sp_counted_baseC2Ev to global weak symbol __ZTVN5boost6detail15sp_counted_baseE means the weak symbol cannot be overridden at runtime. This was likely caused by different translation units being compiled with different visibility settings.
sakra
  • 62,199
  • 16
  • 168
  • 151
  • @StéphanePéchard No, I didn't manage to get rid of the warning. I think you can only get rid of it, if you compile the library (e.g., boost) with the exact same visibility settings. This however does not seem practical for system wide third party libraries. – sakra Dec 13 '11 at 20:26