J <j@xxxxxxxxxx> 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
