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


Ryan Hill <dirtyepic@gentoo.org> writes:

> I don't have a copy of mainline installed, but I do see the error with 4.6
> branch HEAD.  I know at least Debian and Arch have the same problem.
>
> Playing around with the testcase it looks like it works if a C++ module is
> the first to be dlclosed, regardless of the number or order of C/C++
> modules unloaded afterwards, and likewise fails if a C module is closed first.

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 .

Ian

Attachment: bug.tar.bz2
Description: test


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