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
--
users mailing list
users@lists.fedoraproject.org
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

On 07/13/2012 08:26 PM, Skunk Worx wrote:
> Do you think this is a "won't fix" or "not a bug"?

You've already had the correct answer from Ian Taylor on the gcc-help
list. You're not going to get anything more authoritative here.

Andrew.
--
users mailing list
users@lists.fedoraproject.org
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

On 07/14/2012 02:42 AM, Andrew Haley wrote:

On 07/13/2012 08:26 PM, Skunk Worx wrote:

Do you think this is a "won't fix" or "not a bug"?


You've already had the correct answer from Ian Taylor on the gcc-help
list. You're not going to get anything more authoritative here.

Andrew.



I don't see an answer there -- more like a few thoughts that it could be
something in glibc.


I'll post a reminder about this on glibc-help, although they do request
that distro users go through the end user distro processes.


Maybe a tickle after 14 months will get the issue revisited.

---
John
--
users mailing list
users@lists.fedoraproject.org
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

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@lists.fedoraproject.org
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