This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
[Bug c++/71971] Destructor of a global static variable in a shared library is not called on dlclose
- From: "amonakov at gcc dot gnu.org" <gcc-bugzilla at gcc dot gnu dot org>
- To: gcc-bugs at gcc dot gnu dot org
- Date: Mon, 25 Jul 2016 10:07:51 +0000
- Subject: [Bug c++/71971] Destructor of a global static variable in a shared library is not called on dlclose
- Auto-submitted: auto-generated
- References: <bug-71971-4@http.gcc.gnu.org/bugzilla/>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71971
Alexander Monakov <amonakov at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|UNCONFIRMED |RESOLVED
CC| |amonakov at gcc dot gnu.org
Resolution|--- |INVALID
--- Comment #2 from Alexander Monakov <amonakov at gcc dot gnu.org> ---
The library is not unloaded on glibc due to STB_GNU_UNIQUE binding on get::i.
You can opt-out of creating symbols with that binding using -fno-gnu-unique.
But note there was never any guarantee that destructors would be invoked on
dlclose. On musl libc, dlclose is a no-op, and all unloading/destruction
happens on program exit (see the rationale here:
http://wiki.musl-libc.org/wiki/Functional_differences_from_glibc#Unloading_libraries
). For portable code, you cannot assume that dlclose causes immediate
unloading.