|Summary:||sys-libs/libstdc++-v3 sys-devel/gcc:3.3: no version information available in ia64 libstdc++.so|
|Product:||Gentoo Linux||Reporter:||Tim Yamin <plasm>|
|Component:||[OLD] Core system||Assignee:||Gentoo Toolchain Maintainers <toolchain>|
|Package list:||Runtime testing required:||---|
Description Tim Yamin 2012-07-10 19:34:47 UTC
sys-libs/libstdc++-v3 sys-devel/gcc:3.3: no version information available in ia64 libstdc++.so 1. It would be nice to KEYWORD sys-libs/libstdc++-v3 ~ia64 for running old binaries 2. At the same time, it is useful to apply a fix (patch attached) such that version information is produced in the libstdc++.so.5 as right now it isn't and the linker complains when running apps that expect version symbols; a) in testing whether to enable symvers, the libstdc++ configure test fails at the following point: configure:23545: checking for shared libgcc /var/tmp/portage/sys-libs/libstdc++-v3-3.3.6-r1/work/build/gcc/libgcc_s.so: undefined reference to `_Unwind_FindTableEntry' collect2: ld returned 1 exit status b) can fix by ensuring that .c file containing _Unwind_FindTableEntry gets built into libgcc_s such that libgcc_s becomes functional and allows configure check to pass: Before patch: # readelf -a /usr/lib/libstdc++.so.5 | grep Name:.*3.2 <nada...> After patch: # readelf -a /usr/lib/libstdc++.so.5 | grep Name:.*3.2 0x001c: Rev: 1 Flags: none Index: 2 Cnt: 1 Name: GLIBCPP_3.2 0x0038: Rev: 1 Flags: none Index: 3 Cnt: 2 Name: GLIBCPP_3.2.1 0x005c: Rev: 1 Flags: none Index: 4 Cnt: 2 Name: GLIBCPP_3.2.2 0x0080: Rev: 1 Flags: none Index: 5 Cnt: 2 Name: GLIBCPP_3.2.3 0x00a4: Rev: 1 Flags: none Index: 6 Cnt: 2 Name: GLIBCPP_3.2.4
Comment 1 Tim Yamin 2012-07-10 19:35:26 UTC
Created attachment 317850 [details, diff] proposed patch
Comment 2 SpanKY 2012-08-11 17:41:25 UTC
i don't think this ebuild should be building libgcc_s in the first place. just the libstdc++.so lib, and take the rest from the toolchain.
Comment 3 SpanKY 2012-08-12 05:01:44 UTC
hmm, maybe related to bug 304239 ... but that should be fixed in libstdc++-v3-3.3.6-r1 already ...
Comment 4 Tim Yamin 2012-08-12 12:27:49 UTC
I did try -r1, but that wasn't in itself sufficient to fix the problem, which seems to be an ia64-specific b0rkage -- the patch I've attached seems to be necessary.
Comment 5 SpanKY 2012-08-12 14:58:44 UTC
i'm not disputing the fact this fixes the issue you're seeing ;). the trouble is that this change isn't in upstream gcc, and doing newer builds doesn't need this to get symbol versions in libstdc++, so i'd like to address it differently.
Comment 6 SpanKY 2014-08-12 11:29:58 UTC
i don't think we care about gcc-3.3 on ia64 anymore