Hi, on sh, after upgrading to >glibc-2.12(i've tested .12,.13 and .14) and rebuilding world, after building sys-apps/acl, sed segfaults, making the system unable to compile anything since sed is used almost everywhere. Way to reproduce: -extract stage3 -chroot into it -echo sys-libs/glibc >> /etc/portage/package.keywords -emerge -v glibc && emerge -evuDN world This is qlop's -l output: app-portage/portage-utils-0.8 (emerged manually) sys-libs/glibc-2.14.1-r3 sys-libs/zlib-1.2.5-r2 app-arch/xz-utils-5.0.3 virtual/libintl-0 sys-devel/gnuconfig-20120116 virtual/libiconv-0 dev-libs/expat-2.1.0_beta3 app-arch/bzip2-1.0.6-r3 sys-libs/timezone-data-2011n sys-devel/gcc-config-1.5-r2 app-misc/mime-types-8 dev-libs/libffi-3.0.10 sys-apps/tcp-wrappers-7.6-r8 sys-devel/patch-2.6.1 sys-apps/which-2.20 app-portage/portage-utils-0.8 sys-devel/autoconf-wrapper-12 sys-devel/automake-wrapper-6 app-arch/cpio-2.11 app-misc/pax-utils-0.2.3 sys-libs/cracklib-2.8.16 virtual/libffi-0 sys-apps/file-5.09 sys-apps/module-init-tools-3.16-r1 sys-apps/net-tools-1.60_p20110409135728 sys-devel/m4-1.4.15 dev-libs/gmp-5.0.2_p1 sys-apps/sandbox-2.5 virtual/modutils-0 dev-libs/mpfr-3.0.1_p4 dev-libs/mpc-0.8.2 sys-apps/baselayout-2.0.3 sys-devel/libperl-5.10.1 sys-apps/debianutils-3.4.4 virtual/os-headers-0 sys-apps/sysvinit-2.88-r2 virtual/init-0 sys-auth/pambase-20101024-r2 virtual/acl-0-r1 virtual/perl-Scalar-List-Utils-1.230.0-r1 virtual/man-0 sys-apps/man-pages-posix-2003a sys-apps/man-pages-3.36 virtual/pam-0 virtual/shadow-0 app-misc/ca-certificates-20111025 sys-devel/binutils-config-2-r1 app-admin/python-updater-0.10 virtual/perl-libnet-1.220.0-r1 virtual/perl-Digest-SHA-5.47 virtual/perl-Digest-MD5-2.510.0-r1 virtual/perl-digest-base-1.160.0-r1 virtual/perl-Archive-Tar-1.54 virtual/perl-ExtUtils-MakeMaker-6.56 virtual/perl-Test-Simple-0.94 virtual/perl-File-Temp-0.220.0-r1 dev-lang/perl-5.12.4-r1 sys-kernel/linux-headers-2.6.39 dev-perl/Digest-HMAC-1.30.0 perl-core/Scalar-List-Utils-1.230.0 perl-core/Digest-MD5-2.510.0 dev-perl/XML-Parser-2.36-r1 perl-core/version-0.940.0 perl-core/Test-Harness-3.230.0 perl-core/ExtUtils-CBuilder-0.27.03 perl-core/Perl-OSType-1.2.0 perl-core/JSON-PP-2.272.0 perl-core/CPAN-Meta-YAML-0.4.0 perl-core/IO-1.25 perl-core/File-Spec-3.31 dev-perl/Authen-SASL-2.150.0 virtual/perl-version-0.940.0 virtual/perl-ExtUtils-CBuilder-0.27.03 virtual/perl-JSON-PP-2.272.0 virtual/perl-CPAN-Meta-YAML-0.4.0 virtual/perl-Test-Harness-3.230.0-r2 virtual/perl-Perl-OSType-1.2.0 virtual/perl-IO-1.25 virtual/perl-File-Spec-3.31 perl-core/ExtUtils-ParseXS-2.22.05 perl-core/Module-Metadata-1.0.6 perl-core/Parse-CPAN-Meta-1.440.100 perl-core/Version-Requirements-0.101.20 virtual/perl-Parse-CPAN-Meta-1.440.100-r2 virtual/perl-ExtUtils-ParseXS-2.22.05 virtual/perl-Module-Metadata-1.0.6 virtual/perl-Version-Requirements-0.101.20-r2 perl-core/CPAN-Meta-2.112.621 virtual/perl-CPAN-Meta-2.112.621 perl-core/Module-Build-0.380.0 virtual/perl-Module-Build-0.380.0-r2 dev-perl/Error-0.170.160 dev-util/gtk-doc-am-1.18 dev-util/intltool-0.50.0 sys-devel/gettext-0.18.1.1-r1 sys-apps/sed-4.2.1 sys-apps/findutils-4.4.2-r1 dev-libs/popt-1.16-r1 net-misc/rsync-3.0.9 sys-apps/diffutils-3.0 dev-libs/openssl-1.0.0i dev-perl/Net-SSLeay-1.360.0 dev-perl/IO-Socket-SSL-1.440.0 dev-perl/Net-SMTP-SSL-1.10.0 sys-devel/bison-2.4.3 virtual/yacc-0 dev-perl/Locale-gettext-1.50.0 sys-apps/help2man-1.40.5 sys-apps/shadow-4.1.4.3 sys-apps/kbd-1.15.3 sys-apps/gawk-3.1.8 app-arch/tar-1.26 sys-devel/make-3.82-r1 app-arch/gzip-1.4 net-misc/wget-1.12-r3 net-misc/iputils-20101006-r2 sys-apps/texinfo-4.13 sys-apps/ed-1.4 sys-devel/autoconf-2.68 sys-apps/attr-2.4.46-r1 sys-apps/acl-2.2.51 Extracting a binary package of sys-apps/acl (same version), makes sed work again. I've also tried the following: -emerge glibc && emerge -v attr acl and sed still works. I'll try to find what packages are the culprits...hints welcome :)
does it crash if sed is built USE=-acl ?
(In reply to comment #1) > does it crash if sed is built USE=-acl ? Having a broken system, i've done the following: -extract binpkg of sys-apps/acl -USE="-acl" emerge sed && emerge acl -sed works -emerge sed -sed still works
(In reply to comment #2) > (In reply to comment #1) > > does it crash if sed is built USE=-acl ? > > Having a broken system, i've done the following: > -extract binpkg of sys-apps/acl > -USE="-acl" emerge sed && emerge acl > -sed works > -emerge sed > -sed still works Okay, after doing some debugging, the way to reproduce: -emerge >=glibc-2.12* -emerge sed -emerge acl attr(this also pulls in autoconf-wrapper, m4 and autoconf) -sed segfaults
(In reply to comment #3) i can verify this behavior using cross-compilers & qemu. so that's good :). the odd thing is that you need to rebuild & deploy all three for it to crash. if you deploy some, it'll run OK.
hmm, i think it's related to the __gmon_start__() changes ... before glibc-2.12, that symbol was defined in all ELFs, but then it moved to being undefined. i think the core logic is supposed to behave like "if symbol is not defined, skip it", but there's probably a bug in that somewhere. if i create a dummy lib like so: echo '__gmon_start__(){}' | gcc -fPIC -shared -o libfoo.so then preload that: LD_PRELOAD=libfoo.so sed it seems to work fine.
it seems that glibc-2.16 has this fixed (whether on purpose or by accident, i know not). if you could try upgrading your system to that, that'd be great. if it does turn out to work, i'd say let's just wait for that version.
(In reply to comment #6) > it seems that glibc-2.16 has this fixed (whether on purpose or by accident, > i know not). if you could try upgrading your system to that, that'd be > great. if it does turn out to work, i'd say let's just wait for that > version. Nope, same issue
I've bisected it: 9b2f1d4b58f192445db38d5bfe5de0eff2dc3b27 is the first bad commit commit 9b2f1d4b58f192445db38d5bfe5de0eff2dc3b27 Author: Kaz Kojima <kkojima@rr.iij4u.or.jp> Date: Sun Dec 13 09:43:51 2009 -0800 Update sysdeps/sh/elf/initfini.c. :100644 100644 93602d1935a3af3ba011395b209d6e445390c676 db9354489220ea8ba07af1f22e5764139b1fa7c6 M ChangeLog :040000 040000 7568da3c9ea33e3b4f8777bc413cae54c9957c81 33b95a035e7d118d8ac1d96b9a6e3801fe13b479 M sysdeps I'll investigate...
(In reply to comment #8) yes, that is the commit i was referring to when i said the gmon symbol changed. that has no direct relevance in the latest versions since initfini.c has been thrown out in favor of crt[in].S. i'm not familiar with SuperH asm to walk the code and see if there is an error (checking to see if the symbol is non-NULL before attempting to call it).
I'd try masking acl and attr USE-flags, like HPPA does. I tried disabling acl on sed but then after emerging ncurses some portage commands started failing. I'll try with the masking until we have an answer from the glibc maintainers...
i suspect acl/attr aren't the problem. they're just the first libs you ran into.
Thanks to the investigation of Yoshii-san from Renesas we already got the confirmation that the segfault is what is expected. The problem here is that its not possible to upgrade glibc without having to rebuild all the libraries in a specific order(-evuDN world doesn't work here). I'm not sure how we can proceed here considering i haven't got any answer from the glibc SH maintainers. The only way i can think is providing an upgrade guide explaining all the steps the users have to do. Of course those who prefer could start from scratch with the new stage3 we would provide.
Oops, the upgrade path in a clean stage3 would be this(Thanks Yoshii-san): emerge attr acl emerge ncurses readline --nodeps emerge bzip2 cracklib libpcre xz-utils libffi db gdbm tcp-wrappers dev-libs/glib emerge gmp mpfr mpc libxml2 emerge file gettext e2fsprogs-libs e2fsprogs emerge expat emerge openssl emerge curl emerge perl emerge python
i'm going to call it. i don't have the time to investigate and fix this, and at this point, glibc-2.12 was released like 3 years ago. i'm not sure it's even really worth our time either considering SuperH's dead status in the larger scheme of things. i've marked glibc-2.15-r3 stable for sh now: http://sources.gentoo.org/sys-libs/glibc/glibc-2.15-r3.ebuild?r1=1.13&r2=1.14
for posterity, here is what Yoshi had to say: -------- Original Message -------- Subject: Re: Fwd: >=glibc-2.12 issues on gentoo Date: Mon, 15 Oct 2012 15:52:18 +0900 From: Takashi Yoshii <takashi.yoshii.zj@renesas.com> To: Raúl Porcel <armin76@gentoo.org> Sorry for my slow progress. No news is bad news, generally. One month has passed so quickly. I have not get the issue fixed, but it has become quite obvious what is going on. Anyway, I'm now using glibc-2.15-r2 system built by not a smart workaround. Here is a report what I know currently, though you might already know them. Terms in the following context... - "exe" is executable binaries (for example, /bin/sed ) - "lib" is shared libraries (for example, /lib/libattr.so ) - "the change" is commit 9b2f1d4b58f192445db38d5bfe5de0eff2dc3b27 of glibc - "old", "new" means that are built before and after the change. * What is the issue? This is a transition issue of glibc version before and after the change. They are not compatible. The bad case is a combination of (New exe linked with old lib) + New lib. All the other cases including everything new one should work. This hits when you update exe before updating lib they depend on. You must update lib first, then exe. But that is not easy because Gentoo does not have dedicated package for exe and lib (not like as other distributions having XXX and XXX-dev). * Simplified procedure to reproduce the issue. 1. Build lib in old system. 2. Update glibc. 3. Build exe, using old lib. 4. Rebuild lib. 5. Execution of exe fails. Example: ## (setup stage3-sh4-20120307, then) $ echo 'l1(){}' | gcc -xc - -fPIC -shared -o libl1.so $ sudo emerge -K =sys-libs/glibc-2.15-r2 # (package prepared in advance) $ echo 'main(){l1();}' | gcc -xc - -L. -ll1 $ echo 'l1(){}' | gcc -xc - -fPIC -shared -o libl1.so $ LD_LIBRARY_PATH=. ./a.out Segmentation fault * Detailed description The symbol __gmon_start__ is for libc internal use, and most of binaries have a reference to it. It may be left unresolved when it is not used. Before the change, both exe and lib had local __gmon_start__ weak definition (This was somewhat SH specific). The change is to remove this weak definition, so there no longer are these definitions in new exe nor new lib. If an exe is built before lib built, because the compiled obj(.o) no longer has the definition but lib does, the exe gets its __gmon_start__ reference resolved with the lib on link, and successfully bound to the lib on execution. Nothing happens at this point. But then, when lib is re-built, the definition in lib disappears. After that, symbol binding fails while loading, then first init call results in jump to 0, and get SEGV. Example: __gmon_start__ status in the example procedure above. ## Before glibc update. $ objdump -T a.old |grep gmon 004006a0 w DF .text 00000000 Base __gmon_start__ $ objdump -T libl1.so.old |grep gmon 00000500 w DF .text 00000000 Base __gmon_start__ ## Build exe after glibc update $ objdump -T a.out |grep gmon 00400460 w DF UND 00000000 __gmon_start__ ## Build lib after glibc update $ objdump -T libl1.so |grep gmon 00000000 w D UND 00000000 __gmon_start__ ## Build exe after building lib $ objdump -T a.out |grep gmon 00000000 w D UND 00000000 __gmon_start__ * Fix Not yet found. I guess ldso can do some more test to safely ignore this, or possibly we can get the symbol left unresolved at link time. At least, I believe SEGV should be considered as a ldso's bug. This should be "symbol not found" or so, at least, I think. * Workaround. Simply do library update first, then update executable binaries. 1. Careful step by step emerge works. My bash history says I did... | emerge attr acl | emerge ncurses readline --nodeps | emerge bzip2 cracklib libpcre xz-utils libffi db gdbm tcp-wrappers dev-libs/glib | emerge gmp mpfr mpc libxml2 | emerge file gettext e2fsprogs-libs e2fsprogs | emerge expat | emerge openssl | emerge curl | emerge perl | emerge python to rebuild all libs in stage3. I think this one is far overkill, it can be automated more. But ebuild's dependency analysis is not enough, as you know. 2. Cross build works. Because corrupted exe never prevent building process. You might need to build twice in such case, though. 3. Bootstrapping should work. I haven't done yet, though. I do not think this issue matters, because this is an transition issue. /yoshii
