dlclose() doesn't unload any .so that uses Boost

[Ian Lance Taylor]

J <j@jabster.pl> writes:

> I've managed to track this issue down. (Silly me, I should have tried
> this sooner.) It seems this *is* a bug in GCC:
>
> $ g++-4.4 -lboost_signals child.cc -shared -fPIC -o libchild.so
> $ ./host
> host: Loading libchild.so...
> child: Constructor
> host: so = 0x85ab020
> host: Unloading libchild.so...
> child: Destructor
> host: Unloaded.
> host: (nil)
>
> $ g++-4.6 -lboost_signals child.cc -shared -fPIC -o libchild.so
> $ ./host
> host: Loading libchild.so...
> child: Constructor
> host: so = 0x8b34020
> host: Unloading libchild.so...
> host: Unloaded.
> host: (nil)
> child: Destructor
>
> Should I file a bug report?

Over on binutils Jakub points out that this is because gcc 4.6 is
marking symbols that must be unique as STB_GNU_UNIQUE.  This is intended
to make dlopen with RTLD_LOCAL work correctly.  Apparently when a shared
library defines a STB_GNU_UNIQUE symbol the dynamic linker marks that
library so that it is not deleted by dlclose.

gcc's use of STB_GNU_UNIQUE seems correct.  If there is a bug here, I
think it must be in the way the dynamic linker (which is part of glibc)
refuses to permit closing a library which defines a STB_GNU_UNIQUE
symbol.  It seems to me that that is only required if there is in fact
some reference to the symbol from some other shared library.

Ian