Created attachment 312831 [details] config.log Since the armhf ldso change, stable gcc fails to build. The relevant part of the log: Configuring stage 2 in ./intl configure: creating cache ./config.cache checking whether make sets $(MAKE)... yes checking for a BSD-compatible install... /usr/bin/install -c checking whether NLS is requested... no checking for msgfmt... /usr/bin/msgfmt checking for gmsgfmt... /usr/bin/gmsgfmt checking for xgettext... /usr/bin/xgettext checking for msgmerge... /usr/bin/msgmerge checking for armv7a-hardfloat-linux-gnueabi-gcc... /var/tmp/portage/sys-devel/gcc-4.5.3-r2/work/build/./prev-gcc/xgcc -B/var/tmp/portage/sys-devel/gcc-4.5.3-r2/work/build/./prev-gcc/ -B/usr/armv7a-hardfloat-linux-gnueabi/bin/ -B/usr/armv7a-hardfloat-linux-gnueabi/bin/ -B/usr/armv7a-hardfloat-linux-gnueabi/lib/ -isystem /usr/armv7a-hardfloat-linux-gnueabi/include -isystem /usr/armv7a-hardfloat-linux-gnueabi/sys-include checking for C compiler default output file name... a.out checking whether the C compiler works... configure: error: in `/var/tmp/portage/sys-devel/gcc-4.5.3-r2/work/build/intl': configure: error: cannot run C compiled programs. If you meant to cross compile, use `--host'. See `config.log' for more details. make[2]: *** [configure-stage2-intl] Error 1 make[2]: Leaving directory `/var/tmp/portage/sys-devel/gcc-4.5.3-r2/work/build' make[1]: *** [stage2-bubble] Error 2 make[1]: Leaving directory `/var/tmp/portage/sys-devel/gcc-4.5.3-r2/work/build' make: *** [bootstrap-lean] Error 2 emake failed * ERROR: sys-devel/gcc-4.5.3-r2 failed (compile phase): * emake failed with bootstrap-lean Check config.log i'm attaching. Siarhei(in cc) suggested this had to do with the hardfp ldso change. This change was done in stable gcc, but it wasn't done in stable glibc, and i believe this needs to be done on both.
configure:3066: ./a.out /var/tmp/portage/sys-devel/gcc-4.5.3-r2/work/gcc-4.5.3/intl/configure: line 3068: ./a.out: No such file or directory most likely your glibc is using the old ldso path, but gcc is using the new one
i noted this when i posted to the gentoo-dev mailing list. not sure it could be automated because it requires you to: - add a compat ldso symlink in /lib/ from new to old - re-emerge gcc - re-emerge glibc - add a compat ldso symlink in /lib/ from old to new - re-emerge every package - remove compat symlink
(In reply to comment #2) > i noted this when i posted to the gentoo-dev mailing list. not sure it > could be automated because it requires you to: > - add a compat ldso symlink in /lib/ from new to old > - re-emerge gcc > - re-emerge glibc > - add a compat ldso symlink in /lib/ from old to new > - re-emerge every package > - remove compat symlink Okay, to be honest i hit this issue while trying to build new stage3s. This issue can be fixed with what you suggested, however, catalyst in stage1 does ROOT=/tmp/stage1root emerge @system(or something like that). The glibc installed in /tmp/stage1root doesn't create ld-linux-armhf.so.3 which all the binaries are linked to, so it produces a broken stage1. You sure stable glibc, that is 2.14, creates ld-linux-armhf.so.3?
i didn't add the arm hardfp patch to glibc-2.14, so i guess that breaks stable systems w/out recourse. if i just add the patch to 2.14, does that fix your stage building ?
You said you weren't sure if the upgrade could be automated. What about this: -apply patch to stable glibc -make the stable glibc ebuild do a symlink from ld-linux-hardfp.so.3 to ld-linux.so.3 Wouldn't this always work? (In reply to comment #4) > i didn't add the arm hardfp patch to glibc-2.14, so i guess that breaks > stable systems w/out recourse. if i just add the patch to 2.14, does that > fix your stage building ? I tested applying the patch on a normal system, with a gcc already using the new ldso. After emerging glibc obviously all the binaries are broken because they link to ld-linux.so.3 Doing the symlink from ld-linux-armhf.so.3 fixes it, so thats why i think this would always work. On the other hand iirc catalyst sets the "build" USE-flag, so if you don't want to do the symlink always, you can do it if the build use-flag is set. Thanks
Commit message: Backport arm hardfp patch to stable version too http://sources.gentoo.org/gentoo/src/patchsets/glibc/2.14.1/6226_all_arm-glibc-2.15-hardfp.patch?rev=1.1 http://sources.gentoo.org/sys-libs/glibc/glibc-2.14.1-r3.ebuild?r1=1.14&r2=1.15
the other reason i don't want to keep the symlink around is that libs that try to load the ldso will load two copies -- one by the new name and one by the old. so by forcing people to manually do the upgrade, i have a bit more faith they'll rebuild everything. that is probably much less of an issue in practice than the general "everything is now broken". so maybe it's fine. but i don't want to keep it forever ... eventually i want to let their systems break if they didn't rebuild things. maybe do a quick scanelf of /bin /sbin to see if anything needs the old name, and if so, add the symlink. do this in glibc-2.14 and glibc-2.15 ebuilds, but drop it from glibc-2.16+. sound OK ?
Looks okay, thanks
lemme know if this works Commit message: Add backwards compat ldso symlink for arm hardfp targets http://sources.gentoo.org/sys-libs/glibc/glibc-2.14.1-r2.ebuild?r1=1.9&r2=1.10 http://sources.gentoo.org/sys-libs/glibc/glibc-2.14.1-r3.ebuild?r1=1.17&r2=1.18 http://sources.gentoo.org/sys-libs/glibc/glibc-2.14.ebuild?r1=1.16&r2=1.17 http://sources.gentoo.org/sys-libs/glibc/glibc-2.15-r1.ebuild?r1=1.8&r2=1.9 http://sources.gentoo.org/sys-libs/glibc/glibc-2.15-r2.ebuild?r1=1.3&r2=1.4
