[Scons-users] -BSymbolic when linking shared libraries

Gary Oberbrunner garyo at oberbrunner.com
Mon Dec 8 08:27:38 EST 2014


On Mon, Dec 8, 2014 at 5:56 AM, <Hartmut.Brandt at dlr.de> wrote:

> Hi,
>
> I figured out a nasty problem with building shared libraries: when
> building the library with cmake, everything is fine, when building it with
> scons the test programs fail in strange manners. After digging around, I
> found out that scons uses the -Wl,-Bsymbolic unconditionally  on posix
> platforms when linking shared libraries when cmake does not.
>
> After digging around in the internet I think, that this is wrong. The very
> nice paper on shared objects and libraries by Ulrich Drepper (
> http://www.akkadia.org/drepper/dsohowto.pdf) says: "The advice here is to
> never use DF_SYMBOLIC. It does not improve the code, forces all symbols to
> be treated the same, and can cause problems in symbol lookup. It is
> mentioned here only for completeness and as a warning.". Intel warns in
> https://software.intel.com/en-us/articles/performance-tools-for-software-developers-bsymbolic-can-cause-dangerous-side-effects:
> "So as soon as you turn on -Bsymbolic for C++ or Fortran you might expect
> trouble."
>
> In fact, it breaks static class member variables in shared libraries in
> rather subtle ways. Unfortunately it is hard coded in Tool/__init__.py
> (VersionedSharedLibrary()) so that it is not so easy to switch off.
>
> Can we remove this flag or at least make it configurable in some way?
>

This only happens for versioned shared libs, right (when $SHLIBVERSION is
set)?  I think you're right that this should be configurable, and not the
default.  Bsymbolic can in some cases be extremely helpful, but only if you
know exactly why you need it.

-- 
Gary
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://pairlist4.pair.net/pipermail/scons-users/attachments/20141208/d0a3b91a/attachment.html>


More information about the Scons-users mailing list