possible gcc bug?

[Skunk Worx]

On 07/13/2012 12:26 PM, Skunk Worx wrote:
> Hi,
>
> I have an EPEL 6, 64 bit system (SL6) and an fc17 64 bit system.
>
> My shared library uses boost, code synthesis xsd cxx-tree, and xerces-c.
>
> There may be a bug in gcc that prevents this shared library from being
> dlclose()'ed properly :
>
> http://gcc.gnu.org/ml/gcc-help/2011-05/msg00403.html
>
> fc17:
>
> host: Loading libchild.so...
> child: Constructor
> host: so = 0xc0a030
> host: Unloading libchild.so...
> host: Unloaded.
> host: (nil)
> child: Destructor
>
> The following sub-thread implies that this started affecting some
> distributions around gcc version 4.6.0 :
>
> http://gcc.gnu.org/ml/gcc-help/2011-05/msg00432.html
>
> However my EPEL 6 64 is gcc / Red Hat 4.4.6-3 and exhibits the same
> behavior.
>
> Do you think this is a "won't fix" or "not a bug"?
>
> Regards,
> John

The only response from GNU is that the following 2008 POSIX description 
of dlclose() is interpreted as "dlclose() is advisory in nature".

http://pubs.opengroup.org/onlinepubs/9699919799/functions/dlclose.html

They interpret the text as having no requirement for dlclose() to result 
in the destructors being called on a .so file.

In my experience this contradicts everything I've ever seen with the 
dlopen() / dlclose() of an .so file, but that's that.

I'll just have to work around the bloat with a application level .so 
wrapper or something.

---
John