This is the mail archive of the gcc-help@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: 4.6.0: undefined symbol: _ZNSt14error_categoryD2Ev, version GLIBCXX_3.4.15 when dlclose C++ libs from C program


On Sat, 09 Jul 2011 11:11:07 -0700
Ian Lance Taylor <iant@google.com> wrote:

> OK, I managed to recreate the problem with current mainline.  I had to
> use an explicit -lstdc++ when linking test2.so.
> 
> That gives test2.so a DT_NEEDED entry for libstdc++.so.  When the
> test2.so is dlopen'ed, it calls the DT_INIT_ARRAY entries for
> libstdc++.so.  This creates the variables generic_category_instance and
> system_category_instace defined in libstdc++-v3/src/system_error.cc.  It
> also passes the destructor for those variables to __cxa_atexit, along
> with the DSO handle for libstdc++.so.  Later, when test1.so and test2.so
> are dlclose'd, __cxa_finalize is called with DSO handles corresponding
> to test1.so and test2.so, but __cxa_finalize is never called with the
> DSO handle for libstdc++.so.  So the destructors that libstdc++.so
> passed to __cxa_atexit stick around.  When the program exits, the exit
> function calls all the remaining finalizers.  At this point the
> destructor runs, but libstdc++.so has been removed from the symbol map,
> so the symbol resolution error occurs.  It looks like the libstdc++.so
> destructor is not being run because it has a reloc against a
> STB_GNU_UNIQUE symbol.
> 
> I wrote a standalone test case, attached.  This test case recreates the
> problem on Ubuntu Lucid running eglibc 2.11.1-0ubuntu7.8.  However, the
> test case passes on Fedora 14 running glibc 2.13.  So it appears that
> this bug has been fixed in upstream glibc.  I'm not sure which change
> fixes the bug, but it may be the patch for
> http://sourceware.org/bugzilla/show_bug.cgi?id=12510 or
> http://sourceware.org/bugzilla/show_bug.cgi?id=12511 .

Thanks for the analysis, it pointed me in the right direction.  It looks like
STB_GNU_UNIQUE isn't the problem, but that dlclose can fail to update the
symbol search list in some situations.  This patch fixes all the testcases
I've come across:

http://sourceware.org/ml/libc-hacker/2010-05/msg00007.html


-- 
fonts, gcc-porting,                  it makes no sense how it makes no sense
toolchain, wxwidgets                           but i'll take it free anytime
@ gentoo.org                EFFD 380E 047A 4B51 D2BD C64F 8AA8 8346 F9A4 0662

Attachment: signature.asc
Description: PGP signature


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]