From: Ian Lance Taylor <iant@google.com>
To: J <j@jabster.pl>
Cc: David Hagood <david.hagood@gmail.com>, gcc-help@gcc.gnu.org
Subject: Re: dlclose() doesn't unload any .so that uses Boost
Date: Tue, 31 May 2011 17:19:00 -0000 [thread overview]
Message-ID: <mcrd3izrmpi.fsf@coign.corp.google.com> (raw)
In-Reply-To: <BANLkTimM_kOLRGnTmFZ++deWapqae0RMSA@mail.gmail.com> (J.'s message of "Tue, 31 May 2011 08:37:05 +0200")
J <j@jabster.pl> 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
next prev parent reply other threads:[~2011-05-31 14:04 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-05-30 0:24 J
2011-05-30 5:23 ` David Hagood
2011-05-30 18:53 ` J
2011-05-31 6:01 ` Ian Lance Taylor
2011-05-31 12:30 ` J
2011-05-31 17:19 ` Ian Lance Taylor [this message]
2011-05-30 23:10 ` Pavel Tolkachev
2011-05-30 23:19 ` J
2011-05-31 5:49 ` Pavel Tolkachev
2011-05-31 5:54 ` J
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=mcrd3izrmpi.fsf@coign.corp.google.com \
--to=iant@google.com \
--cc=david.hagood@gmail.com \
--cc=gcc-help@gcc.gnu.org \
--cc=j@jabster.pl \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).