possible gcc bug?
On 07/13/2012 12:26 PM, Skunk Worx wrote:
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 :
host: Loading libchild.so...
host: so = 0xc0a030
host: Unloading libchild.so...
The following sub-thread implies that this started affecting some
distributions around gcc version 4.6.0 :
However my EPEL 6 64 is gcc / Red Hat 4.4.6-3 and exhibits the same
Do you think this is a "won't fix" or "not a bug"?
The only response from GNU is that the following 2008 POSIX description
of dlclose() is interpreted as "dlclose() is advisory in nature".
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.
users mailing list
To unsubscribe or change subscription options:
Have a question? Ask away: http://ask.fedoraproject.org