Created attachment 372064 [details] backtrace (sys-libs/glibc-2.18-r1,sys-devel/binutils-2.24-r2,sys-devel/gcc-4.8.2) I tried to build sys-libs/glibc-2.17 and sys-libs/glibc-2.18-r1 with sys-devel/binutils-2.23.2 or sys-devel/binutils-2.24-r2 and sys-devel/gcc-4.8.2, but always run into the same error in the pkg_preinst stage: /var/cache/portage/gentoo/sys-libs/glibc/files/eblits/pkg_preinst.eblit: line 21: 9222 Segmentation fault ./ld-*.so --library-path . ${x} > /dev/null * ERROR: sys-libs/glibc-2.18-r1::gentoo failed (preinst phase): * simple run test (/bin/date) failed * Please find a backtrace for the sys-libs/glibc-2.18-r1,sys-devel/binutils-2.24-r2,sys-devel/gcc-4.8.2 combination attached. The context of the crash is (according to glibc-2.18/elf/get-dynamic-info.h): elf_get_dynamic_info (struct link_map *l, ElfW(Dyn) *temp) { ElfW(Dyn) **info; info = l->l_info; info[DT_ADDRTAGIDX (dyn->d_tag) + DT_NUM + DT_THISPROCNUM + DT_VERSIONTAGNUM + DT_EXTRANUM + DT_VALNUM] = dyn; } GDB reports this function being called as: elf_get_dynamic_info (temp=0x0, l=0x2000000800051458 <_rtld_local+2456>) What I find to be suspicious is the changed order of parameters. I would like to check this with valgrind, too, but it is hardmasked for ia64 (i.e. anything but x86, ppc and arm).
P.S: It crashes in exactly the same way when running without --library-path and when running with ../usr/bin/locale as argument.
Created attachment 372070 [details] emerge --info Since sys-libs/glibc-2.17 compiled fine with sys-devel/gcc-4.7.3, I assume that sys-devel/gcc-4.8.2 is to blame. See-Also: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60465
you're running a hardened system, but it reproduces on a normal system too
building all of glibc w/4.8 and then rebuilding just elf/rtld.c w/4.7 works
i suspect bad code generation from gcc. you should update your bug with the fields i entered in the duplicate report.
*** Bug 536940 has been marked as a duplicate of this bug. ***
This is reproducible in gcc-4.8.4 with glibc-2.20-r2, errors I got are... >>> Done. * checking 1403 files for package collisions 1000 files checked ... >>> Merging sys-libs/glibc-2.20-r2 to / * Defaulting /etc/host.conf:multi to on /usr/portage/sys-libs/glibc/files/eblits/pkg_preinst.eblit: line 24: 15682 Segmentation fault ./ld-*.so --library-path . ${x} > /dev/null * ERROR: sys-libs/glibc-2.20-r2::gentoo failed (preinst phase): * simple run test (/usr/bin/cal) failed * --snip--- * !!! FAILED preinst: 1
I get the same. On a non harden install. # gcc --version gcc (GCC) 4.8.2 20130815 (prerelease) and glibc-2.20-r2 message : ecompressdir: bzip2 -9 /usr/share/man * checking 1439 files for package collisions 1000 files checked ... >>> Merging sys-libs/glibc-2.20-r2 to / * Defaulting /etc/host.conf:multi to on /usr/portage/sys-libs/glibc/files/eblits/pkg_preinst.eblit: line 24: 21352 Segme ntation fault ./ld-*.so --library-path . ${x} > /dev/null * ERROR: sys-libs/glibc-2.20-r2::gentoo failed (preinst phase): * simple run test (/usr/bin/cal) failed
I also get it on : glibc-2.19-r1 1000 files checked ... >>> Merging sys-libs/glibc-2.19-r1 to / * Defaulting /etc/host.conf:multi to on /usr/portage/sys-libs/glibc/files/eblits/pkg_preinst.eblit: line 24: 16154 Segmentation fault ./ld-*.so --library-path . ${x} > /dev/null * ERROR: sys-libs/glibc-2.19-r1::gentoo failed (preinst phase): * simple run test (/usr/bin/cal) failed
Naive question there: is this only a problem between glibc and gcc-4.8, or is it a sign of something more seriously broken in gcc-4.8 that will break many other packages on ia64? Émeric
I have the same issue with gcc-4.9.3
Still an issue : 1000 files checked ... >>> Merging sys-libs/glibc-2.21-r1 to / * Defaulting /etc/host.conf:multi to on /usr/portage/sys-libs/glibc/files/eblits/pkg_preinst.eblit: line 24: 32147 Segmentation fault LC_ALL=C ./ld-*.so --library-path . ${x} > /dev/null * ERROR: sys-libs/glibc-2.21-r1::gentoo failed (preinst phase): * simple run test (/usr/bin/cal) failed * Using sys-libs/glibc-2.21-r1 and sys-devel/gcc-4.7.4
I've found a weird workaround for it (the same crash as in comment #1): building glibc-2.22-r1 with LDFLAGS="-Wl,--hash-style=sysv" instead of --hash-style=gnu makes glibc install fine. I'll explore why exactly rtld crashes.
(In reply to Sergei Trofimovich from comment #13) > I've found a weird workaround for it (the same crash as in comment #1): > > building glibc-2.22-r1 with > LDFLAGS="-Wl,--hash-style=sysv" > instead of --hash-style=gnu makes glibc install fine. > > I'll explore why exactly rtld crashes. This works for me. I can build glibc-2.17 and glibc-2-21 with no issues. LDFLAGS="${LDFLAGS} -Wl,--hash-style=sysv" emerge -av sys-libs/glibc
Created attachment 420900 [details, diff] 0001-elf-get-dynamic-info.h-fix-early-GNU_HASH-processing.patch This workaround makes GNU_HASH load work correctly on gcc-4.9.3. Sent it upstream: https://sourceware.org/ml/libc-alpha/2015-12/msg00556.html
i've deployed the workaround to glibc: http://gitweb.gentoo.org/repo/gentoo.git/commit/?id=cbd2a52033efd9a333508d5cd9bd35bd00a2c06b we can address the proper fix in the respective upstreams
upstream gcc fix: https://github.com/gcc-mirror/gcc/commit/afe82e5b25dda439d84a99d95b3767d6cced79c8
i've queued the 4.9 & 5 backports here: https://sources.gentoo.org/gentoo/src/patchsets/gcc/4.9.3/gentoo/36_all_gcc-ia64-pr60465.patch?rev=1.1 https://sources.gentoo.org/gentoo/src/patchsets/gcc/5.3.0/gentoo/36_all_gcc-ia64-pr60465.patch?rev=1.1 should be all set now. thanks for fixing this Sergei!
(In reply to SpanKY from comment #18) > i've queued the 4.9 & 5 backports here: > https://sources.gentoo.org/gentoo/src/patchsets/gcc/4.9.3/gentoo/36_all_gcc- > ia64-pr60465.patch?rev=1.1 > https://sources.gentoo.org/gentoo/src/patchsets/gcc/5.3.0/gentoo/36_all_gcc- > ia64-pr60465.patch?rev=1.1 > > should be all set now. thanks for fixing this Sergei! Do we need updated glibc to definitely fix this issue? As I've already reported in https://bugs.gentoo.org/show_bug.cgi?id=518130#c5, gdb is still failing when booting kernel built with gcc 4.9 (no problem when built with gcc 4.5). All this with current ia64 stable stack: - sys-devel/binutils-2.25.1-r1 - sys-devel/gcc-4.9.3 - sys-devel/gdb-7.10.1 - sys-kernel/gentoo-sources-4.1.12 - sys-libs/glibc-2.21-r1 Among other oddities, mail-client/evolution:2.0 is failing with: /usr/lib/gcc/ia64-unknown-linux-gnu/4.9.3/../../../libwebkitgtk-3.0.so: undefined reference to `std::chrono::steady_clock::now()@GLIBCXX_3.4.17' I've however rebuilt both sys-devel/glibc and net-libs/webkit-gtk using gcc 4.9. This doesn't happen when building with gcc 4.7. Can you please double-check on your side? Thanks, Émeric
(In reply to Émeric Maschino from comment #19) this bug is only about glibc crashing early. a workaround was added to current glibc versions, and the fix to not make it crash added to current gcc versions. any other issue is unrelated to this bug.
> (In reply to SpanKY from comment #20) > > this bug is only about glibc crashing early. a workaround was added to > current glibc versions, and the fix to not make it crash added to current > gcc versions. any other issue is unrelated to this bug. So, I'm lost ;-) Following resolution of this bug, why was bug #518130 then closed, saying that it should resolved by itself now that gcc 4.8/4.9 is ia64 stable [1]? That's indeed not the case actually. Émeric [1] https://bugs.gentoo.org/show_bug.cgi?id=518130#c3
> As I've already reported in > https://bugs.gentoo.org/show_bug.cgi?id=518130#c5, gdb is still failing when > booting kernel built with gcc 4.9 (no problem when built with gcc 4.5). All > this with current ia64 stable stack: > - sys-devel/binutils-2.25.1-r1 > - sys-devel/gcc-4.9.3 > - sys-devel/gdb-7.10.1 > - sys-kernel/gentoo-sources-4.1.12 > - sys-libs/glibc-2.21-r1 Sounds like a different gcc/gdb/kernel bug. I suggest filing a new report with reference to bug #518130 as bug claims gdb worked at some point around gcc-4.8. > Among other oddities, mail-client/evolution:2.0 is failing with: > > /usr/lib/gcc/ia64-unknown-linux-gnu/4.9.3/../../../libwebkitgtk-3.0.so: > undefined reference to `std::chrono::steady_clock::now()@GLIBCXX_3.4.17' > > I've however rebuilt both sys-devel/glibc and net-libs/webkit-gtk using gcc > 4.9. This doesn't happen when building with gcc 4.7. > > Can you please double-check on your side? gcc changed ABI for some C++ symbols and all binaries trying to use that require recompilation. It's a bug #513386 which has some hints and a news item: https://www.gentoo.org/support/news-items/2015-10-22-gcc-5-new-c++11-abi.html Which means you need to rebuild some c++ stuff after compiler switch.
(In reply to Émeric Maschino from comment #21) bug 518130 isn't about linking at all. let's keep discussion of that bug there.
5.3.0 p1.1 containing this patch is now in the tree.
