In trying to help a couple people install a new system, and duplicating their actions in a chroot on my system. Gcc fails to configure properly when it starts building inside bootstrap. Reproducible: Always Steps to Reproduce: - make a Chroot and follow standard install instructions. - bootstrap.sh fails immedetely, due to gcc-config problem. [Unknown bug #] - # gcc-config 2; source /etc/profile; gcc-config 1; source /etc/profile Fixes the problem (See Attachment for Details) - Bootstrap runs clean until error below. Actual Results: Get this error: checking build system type... x86_64-pc-linux-gnu checking host system type... x86_64-pc-linux-gnu checking target system type... x86_64-pc-linux-gnu checking for a BSD-compatible install... /bin/install -c checking whether build environment is sane... yes checking for gawk... gawk checking whether make sets $(MAKE)... yes checking for x86_64-pc-linux-gnu-gcc... /var/tmp/portage/gcc-3.4.3-r1/work/build/gcc/xgcc -B/var/tmp/portage/gcc-3.4.3-r1/work/build/gcc/ -B/usr/x86_64-pc-linux-gnu/bin/ -B/usr/x86_64-pc-linux-gnu/lib/ -isystem /usr/x86_64-pc-linux-gnu/include -isystem /usr/x86_64-pc-linux-gnu/sys-include -m32 checking for C compiler default output... a.out checking whether the C compiler works... configure: error: cannot run C compiled programs. If you meant to cross compile, use `--host'. See `config.log' for more details. make[1]: *** [configure-target-libstdc++-v3] Error 1 make[1]: Leaving directory `/var/tmp/portage/gcc-3.4.3-r1/work/build' make: *** [profiledbootstrap] Error 2 !!! ERROR: sys-devel/gcc-3.4.3-r1 failed. !!! Function gcc_do_make, Line 1113, Exitcode 2 !!! make failed with profiledbootstrap !!! If you need support, post the topmost build error, NOT this status message. Expected Results: I expect it to compiles cleanly. emerge info From inside CHROOT: Portage 2.0.51-r15 (default-linux/amd64/2004.3, gcc-3.4.2, glibc-2.3.4.20041102-r0, 2.6.10-gentoo-r7 x86_64) ================================================================= System uname: 2.6.10-gentoo-r7 x86_64 AMD Athlon(tm) 64 Processor 3200+ Gentoo Base System version 1.4.16 Python: [2.3.4 (#1, Oct 28 2004, 03:17:30)] dev-lang/python: [Not Present] sys-devel/autoconf: [Not Present] sys-devel/automake: [Not Present] sys-devel/binutils: 2.15.92.0.2-r1 sys-devel/libtool: [Not Present] virtual/os-headers: 2.6.8.1-r2 ACCEPT_KEYWORDS="amd64" AUTOCLEAN="yes" CFLAGS="-O2 -pipe -mtune=athlon64" CHOST="x86_64-pc-linux-gnu" CONFIG_PROTECT="/etc /usr/kde/2/share/config /usr/kde/3.3/env /usr/kde/3.3/share/config /usr/kde/3.3/shutdown /usr/kde/3/share/config /usr/lib/X11/xkb /usr/lib/mozilla/defaults/pref /usr/share/config /usr/share/texmf/dvipdfm/config/ /usr/share/texmf/dvips/config/ /usr/share/texmf/tex/generic/config/ /usr/share/texmf/tex/platex/config/ /usr/share/texmf/xdvi/ /var/qmail/control" CONFIG_PROTECT_MASK="/etc/gconf /etc/terminfo /etc/env.d" CXXFLAGS="-O2 -pipe -mtune=athlon64" DISTDIR="/usr/portage/distfiles" FEATURES="autoaddcvs autoconfig ccache distlocks sandbox" GENTOO_MIRRORS="http://distfiles.gentoo.org http://distro.ibiblio.org/pub/Linux/distributions/gentoo" MAKEOPTS="-j2" PKGDIR="/usr/portage/packages" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" SYNC="rsync://rsync.gentoo.org/gentoo-portage" USE="amd64 acpi alsa berkdb bitmap-fonts crypt f77 font-server fortran gif gpm ipv6 jp2 jpeg lzw lzw-tiff multilib ncurses nls opengl oss pam perl png python readline ssl tcpd tiff truetype truetype-fonts type1-fonts usb userlocales xml2 xpm xrandr xv zlib" Unset: ASFLAGS, CBUILD, CTARGET, LANG, LC_ALL, LDFLAGS, PORTDIR_OVERLAY Please see attached Files.
Created attachment 51230 [details] Full details of steps to reproduce
Created attachment 51231 [details] emerge.log from in the chroot
I have found a temporary work-around until such time as this problem is fixed. It's really quite simple. Use a portage snapshot that is dated on or before 2005-02-08. It seems that someone playing with gcc and/or bootstrap.sh inadvertently broke something on amd64. # irsii /join #gentoo-amd64 There are a couple of us in there in the same situation.
have them try "emerge -e system" works pretty well, too... or they could use bootstrap-new.sh and emerge -e system in conjunction, as that is how 2005.0 will work
*** Bug 82104 has been marked as a duplicate of this bug. ***
Please attatch the config.log which shows the failure as well .
Ok, I think I found the cause. When building portage it will check for multilib-abis. With the 2004.3 profile, this contains default. This will as a consequence not lead to the 32 bit sandbox being built. Next a similar problem exists for newlib.so (or dolib)
In short adding the following to make.conf fixed it for me: MULTILIB_ABIS="x86 amd64" DEFAULT_ABI="amd64" LIBDIR_amd64="lib64" LIBDIR_x86="lib32"
The error is that sandbox can't be found. At this point I still can not get it to be found allthough it's certainly there
the problem was that the portage ebuild was checking ${MULTILIB_ABIS} directly rather than using multilib.eclass's has_multilib_profile. This has been fixed in cvs. resync, re-emerge portage, and you'll be good to go.
What version of portage has this fixed? We're going to have to resnapshot and rebuild all stages on all architectures before the release due to this.
It was the ebuild, not portage itself. I fixed all versions in the tree. You don't need to resnapshot. The only people who were affected by this were 2004.3 amd64 because it only made the 64bit libsandbox.
*** Bug 82553 has been marked as a duplicate of this bug. ***
Please reopen. It's not been solved yet. See Bug 82553 for details.
I've been working on a clean install last night, but bootstrapping still ends prematurely while compiling gcc (same error message). The problem doesn't seem to be solved.
Created attachment 51745 [details] config.log of gcc-3.4.3-r1
That's the wrong config.log. gcc has separate config.logs for each sup-package You want the one for libstdc++-v3/32 MWen: emerge --sync && FEATURES=-sandbox emerge porgage
Confirmed working after chrooting from a clean stage1: 1] Bootstrap, wait for gcc error 2] FEATURES="-sandbox" emerge portage 3] USE="multilib" emerge gcc 4] env-update && source /etc/profile 5] emerge portage 6] Continue bootstrap However, Portage 2.0.51-(r14|r15) does not install a 32-bit sandbox in /lib32 (which was already reported by Karsten Becker, bug 82553). Emerging 2.0.51-r3 does install the sandbox.
Created attachment 51862 [details] config.log @ Jeremy Huddleston: If that's the config.log you need: /var/tmp/portage/gcc-3.4.3-r1/work/build/x86_64-pc-linux-gnu/libstdc++-v3/config.log Here it is.
Well, because I think we move around in circles here, I get away with doing a summary of the problems we have. Additionally I would like to allude, that although I'm not an official Gentoo bug-fixer, I'm working as a C developer for three years now (developing apps for Sparc/Linux/W32/zOS/AIX), so I hope I'm close to the solution. We have 2 seperate problems here: 1. Portage is only half-fixed. It builds the 32bit linsandbox.so, but it doesn't install it. That's a gcc-independent problem. You can see it here: desktop lib # emerge portage Calculating dependencies ...done! >>> emerge (1 of 1) sys-apps/portage-2.0.51-r15 to / >>> md5 src_uri ;-) portage-2.0.51-r15.tar.bz2 >>> Unpacking source... >>> Unpacking portage-2.0.51-r15.tar.bz2 to /var/tmp/portage/portage-2.0.51-r15/work >>> Source unpacked. * Found valid multilib environment. * Building with multilib support. ./create-localdecls Checking truncate argument type... off_t Checking libc version... libc.so.6 Checking glibc subversion... 2.3 x86_64-pc-linux-gnu-gcc -O1 -pipe -m64 -D_GNU_SOURCE -DPIC -fPIC -D_REENTRANT -DSB_HAVE_64BIT_ARCH -Wall -c libsandbox.c x86_64-pc-linux-gnu-gcc -O1 -pipe -m64 -D_GNU_SOURCE -DPIC -fPIC -D_REENTRANT -DSB_HAVE_64BIT_ARCH -Wall -c sandbox_futils.c -o sandbox_futils.o x86_64-pc-linux-gnu-gcc libsandbox.o sandbox_futils.o -shared -m64 -fPIC -ldl -lc -nostdlib -lgcc -o libsandbox.so x86_64-pc-linux-gnu-gcc -O1 -pipe -m32 -D_GNU_SOURCE -DPIC -fPIC -D_REENTRANT -DSB_HAVE_64BIT_ARCH -Wall -c libsandbox.c -o libsandbox32.o x86_64-pc-linux-gnu-gcc -O1 -pipe -m32 -D_GNU_SOURCE -DPIC -fPIC -D_REENTRANT -DSB_HAVE_64BIT_ARCH -Wall -c sandbox_futils.c -o sandbox_futils32.o x86_64-pc-linux-gnu-gcc libsandbox32.o sandbox_futils32.o -shared -m32 -fPIC -ldl -lc -nostdlib -lgcc -o libsandbox32.so x86_64-pc-linux-gnu-gcc -O1 -pipe -m64 -D_GNU_SOURCE -DPIC -fPIC -D_REENTRANT -DSB_HAVE_64BIT_ARCH -Wall -c sandbox.c -o sandbox.o x86_64-pc-linux-gnu-gcc -O1 -pipe -m64 -D_GNU_SOURCE -DPIC -fPIC -D_REENTRANT -DSB_HAVE_64BIT_ARCH -Wall sandbox.o sandbox_futils.o getcwd.c -ldl -lc -o sandbox >>> Test phase [not enabled]: sys-apps/portage-2.0.51-r15 >>> Install portage-2.0.51-r15 into /var/tmp/portage/portage-2.0.51-r15/image/ category sys-apps install -d -m 0755 /var/tmp/portage/portage-2.0.51-r15/image//lib install -d -m 0755 /var/tmp/portage/portage-2.0.51-r15/image//usr/lib/portage/bin install -d -m 0755 /var/tmp/portage/portage-2.0.51-r15/image//usr/lib/portage/lib install -m 0755 libsandbox.so /var/tmp/portage/portage-2.0.51-r15/image//lib install -m 0755 sandbox /var/tmp/portage/portage-2.0.51-r15/image//usr/lib/portage/bin install -m 0644 sandbox.bashrc /var/tmp/portage/portage-2.0.51-r15/image//usr/lib/portage/lib man: ... This was reported with Bug 82553. 2. When trying to compile gcc (with multilib and sandbox), it will not find a 32bit sandbox when going to compile the 'libstdc++-v3'-part. Even if portage would install a libsandbox.so in /lib32, what older versions seemed to do, it will not work. I tried that with a 32bit libsandbox.so of a stage3-tarball. This behaviour is caused of the configure-scripts of gcc, because they don't include the /lib32 as a library path (see attached config.log, 2005-02-22 00:006 PST). If I add a symlink /usr/x86_64-pc-linux-gnu/lib/libsandbox.so, pointing to /lib32/libsandbox.so (of the stage3-tarball), it works. So either portage has to create that symlink, or the configure-scripts of gcc must be modified to take /lib32 into account. I would prefer the first solution of the symlink.
(1) Fixed. (2) Yes, it does work. LD_PRELOAD uses /etc/ld.so.cache. Also, binutils uses /lib32, and gcc uses ../lib32
I can confirm the fix(es). portage compiled & installed libsandbox32.so again and gcc finished one minute ago. Thanks a lot for your patience and work.
Moving these so we can remove the "Install CD" component from "Gentoo Linux". I apologize to everyone for this spam, but according to the bugzilla developers, this is the only reasonable way to do this.