This is the mail archive of the
gcc-help@gcc.gnu.org
mailing list for the GCC project.
Re: dlclose() doesn't unload any .so that uses Boost
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