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
--
users mailing list
users@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe or change subscription options:
https://admin.fedoraproject.org/mailman/listinfo/users
Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines
Have a question? Ask away: http://ask.fedoraproject.org
