| Summary: | gcc-config says 3.4, but programs still link against libstdc++.so.5 | ||
|---|---|---|---|
| Product: | Gentoo Linux | Reporter: | mwahl <markus.wahl> |
| Component: | New packages | Assignee: | Gentoo Toolchain Maintainers <toolchain> |
| Status: | VERIFIED INVALID | ||
| Severity: | normal | CC: | sci |
| Priority: | High | ||
| Version: | 2006.0 | ||
| Hardware: | x86 | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
|
Description
mwahl
2006-06-01 17:38:02 UTC
Reopen w/ a backtrace. http://www.gentoo.org/proj/en/qa/backtraces.xml Followed the guide. Please tell me if there is still information missing or if I have to build deeper with FEATURES="splitdebug". Starting program: /usr/bin/ghemical /usr/bin/ghemical: Symbol `_ZTVSt15basic_stringbufIcSt11char_traitsIcESaIcEE' has different size in shared object, consider re-linking [Thread debugging using libthread_db enabled] [New Thread -1228162848 (LWP 1828)] Program received signal SIGSEGV, Segmentation fault. [Switching to Thread -1228162848 (LWP 1828)] 0xb6d0d9a6 in std::locale::operator= () from /usr/lib/gcc-lib/i686-pc-linux-gnu/3.3.6/libstdc++.so.5 (gdb) bt #0 0xb6d0d9a6 in std::locale::operator= () from /usr/lib/gcc-lib/i686-pc-linux-gnu/3.3.6/libstdc++.so.5 #1 0xb6d06b4f in std::ios_base::_M_init () from /usr/lib/gcc-lib/i686-pc-linux-gnu/3.3.6/libstdc++.so.5 #2 0xb6d050b1 in std::basic_ios<char, std::char_traits<char> >::init () from /usr/lib/gcc-lib/i686-pc-linux-gnu/3.3.6/libstdc++.so.5 #3 0xb7123738 in default_tables (this=0x8102428) at fstream:512 #4 0xb7124c99 in default_tables::GetInstance () at tab_mm_default.cpp:205 #5 0xb712e578 in global constructors keyed to _ZN14default_tables8instanceE () at utility.h:81 #6 0xb73e3145 in __do_global_ctors_aux () from /usr/local/lib/libghemical.so.0 #7 0xb70b9a91 in _init () from /usr/local/lib/libghemical.so.0 #8 0xb7f88a0b in call_init () from /lib/ld-linux.so.2 #9 0xb7f88abd in _dl_init_internal () from /lib/ld-linux.so.2 #10 0xb7f7d80f in _dl_start_user () from /lib/ld-linux.so.2 This looks like a problem introduced by your toolchain upgrades. See how you're still linked against libstdc++.so.5 rather than the .so.6? Did you properly select the new compiler using gcc-config? I'd suggest doing that and rebuilding glibc, binutils, gcc, libghemical, ghemical again. I checked gcc-config -l: [1] i686-pc-linux-gnu-3.3.6 [2] i686-pc-linux-gnu-3.3.6-hardened [3] i686-pc-linux-gnu-3.3.6-hardenednopie [4] i686-pc-linux-gnu-3.3.6-hardenednopiessp [5] i686-pc-linux-gnu-3.3.6-hardenednossp [6] i686-pc-linux-gnu-3.4.6 * [7] i686-pc-linux-gnu-3.4.6-hardened [8] i686-pc-linux-gnu-3.4.6-hardenednopie [9] i686-pc-linux-gnu-3.4.6-hardenednopiessp [10] i686-pc-linux-gnu-3.4.6-hardenednossp And then emerged glibc, binutils, gcc did a "source /etc/profile" and then emerged libghemical and ghemical Same result. Still uses libstdc++.so.5, only the backtrace has some more information in the topmost layer probably due to the -ggdb rebuild of glibc. #8 0xb7f04a0b in call_init (l=0xb7588cd0, argc=1, argv=0xbfb0c9c4, env=0xbfb0c9cc) at dl-init.c:70 #9 0xb7f04abd in _dl_init (main_map=0xb7f0f4e8, argc=1, argv=0xbfb0c9c4, env=0xbfb0c9cc) at dl-init.c:142 #10 0xb7ef980f in _dl_start_user () at rtld.c:577 This seems like it could be some sort of gcc-config problem. Programs should be linking with libstdc++.so.6 when you have gcc 3.4 selected, not libstdc++.so.5. much more likely you have something still linked against libstdc++.so.5 and when you rebuilt some of the other apps, they got linked against both (In reply to comment #6) > much more likely you have something still linked against libstdc++.so.5 and > when you rebuilt some of the other apps, they got linked against both So what exactly is a possible solution? emerge -e system emerge -e system emerge -e world emerge -e world Or should I use this emwrap.sh to rebuild the toolchain and then system & world? When do I need to run fix_libtool.sh and what does it change? I unfortuneately don't understand the whole concept with the different libstdc++ too well. Are those libstdc++ coming from glibc or from gcc? Would it help to clean/prune the old gcc 3.3.6 version still installed on my system or is this even dangerous? thanx 10x in advance! I did an emerge -e system && emerge -e system && emerge -e world And I unmerged gcc-3.3.6 and reemerged libghemical. Now the backtrace changed a little, but the seg fault still persists. ERROR: duplicate ClassDesc detected for class DescribedClass type_info name = N2sc14DescribedClassE Program received signal SIGABRT, Aborted. [Switching to Thread -1305262400 (LWP 31100)] 0xffffe410 in __kernel_vsyscall () Current language: auto; currently c (gdb) bt #0 0xffffe410 in __kernel_vsyscall () #1 0xb284fd3d in *__GI_raise (sig=6) at raise.c:64 #2 0xb2851353 in *__GI_abort () at abort.c:88 #3 0xb741fb65 in sc::ClassDesc::ClassDesc () from /usr/local/lib/libghemical.so.0 #4 0xb7422cf7 in __static_initialization_and_destruction_0 () from /usr/local/lib/libghemical.so.0 #5 0xb7422d52 in global constructors keyed to _ZN2sc9ClassDesc4all_E () from /usr/local/lib/libghemical.so.0 #6 0xb7446145 in __do_global_ctors_aux () from /usr/local/lib/libghemical.so.0 #7 0xb711ca91 in _init () from /usr/local/lib/libghemical.so.0 #8 0xb7fe8a0b in call_init (l=0xb766ba58, argc=1, argv=0xbf8f0ab4, env=0xbf8f0abc) at dl-init.c:70 #9 0xb7fe8abd in _dl_init (main_map=0xb7ff34e8, argc=1, argv=0xbf8f0ab4, env=0xbf8f0abc) at dl-init.c:142 #10 0xb7fdd80f in _dl_start_user () at rtld.c:577 Any other ideas? (In reply to comment #8) > #3 0xb741fb65 in sc::ClassDesc::ClassDesc () from > /usr/local/lib/libghemical.so.0 /usr/local? Surely the ebuild will be putting libghemical in /usr/lib. /usr/local usually means you've built it manually yourself at some point. Try removing it from /usr/local/lib (In reply to comment #9) > /usr/local usually means you've built it manually yourself at some point. > > Try removing it from /usr/local/lib Shame on me!!! Yes, I built it manually before and after deleting everything libghemical* in /usr/local/lib it works fine. I even figured out I had two ghemical main programs hanging around. The first error messages with libstdc++ took me on a wrong trip. Thank you very much for your help and enlightment. Just for curiosity: Do there exist any rules or basic considerations where installed software should place its files? The error <<has different size in shared object, consider re-linking>> can be fixed by remergint the package owning the file. See bug 338347 . The issue is not in the app, but in portage 2.2, or in revdep-rebuild. |
