Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 82027 - bootstrap.sh fails on rebuild of gcc on amd64
Summary: bootstrap.sh fails on rebuild of gcc on amd64
Status: VERIFIED FIXED
Alias: None
Product: Gentoo Release Media
Classification: Unclassified
Component: Everything (show other bugs)
Hardware: AMD64 Linux
: High normal (vote)
Assignee: Gentoo LiveCD Package Maintainers
URL:
Whiteboard:
Keywords:
: 82104 82553 (view as bug list)
Depends on:
Blocks:
 
Reported: 2005-02-14 12:15 UTC by Lares Moreau
Modified: 2005-03-25 11:25 UTC (History)
5 users (show)

See Also:
Package list:
Runtime testing required: ---


Attachments
Full details of steps to reproduce (full.details.txt,4.27 KB, text/plain)
2005-02-14 12:18 UTC, Lares Moreau
Details
emerge.log from in the chroot (emerge.log,10.17 KB, text/plain)
2005-02-14 12:18 UTC, Lares Moreau
Details
config.log of gcc-3.4.3-r1 (gcc-3.4.3-r1 config.log,1.78 KB, text/plain)
2005-02-20 20:21 UTC, Michel Wendrich
Details
config.log (config.log,314.14 KB, text/plain)
2005-02-22 00:06 UTC, Karsten Becker
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Lares Moreau 2005-02-14 12:15:18 UTC
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.
Comment 1 Lares Moreau 2005-02-14 12:18:01 UTC
Created attachment 51230 [details]
Full details of steps to reproduce
Comment 2 Lares Moreau 2005-02-14 12:18:26 UTC
Created attachment 51231 [details]
emerge.log from in the chroot
Comment 3 Lares Moreau 2005-02-15 04:39:18 UTC
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.
Comment 4 Chris Gianelloni (RETIRED) gentoo-dev 2005-02-15 05:33:01 UTC
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
Comment 5 Simon Stelling (RETIRED) gentoo-dev 2005-02-15 08:40:44 UTC
*** Bug 82104 has been marked as a duplicate of this bug. ***
Comment 6 Jeremy Huddleston (RETIRED) gentoo-dev 2005-02-17 11:49:56 UTC
Please attatch the config.log which shows the failure as well .
Comment 7 Paul de Vrieze (RETIRED) gentoo-dev 2005-02-17 14:01:38 UTC
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)
Comment 8 Paul de Vrieze (RETIRED) gentoo-dev 2005-02-17 14:04:51 UTC
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"
Comment 9 Paul de Vrieze (RETIRED) gentoo-dev 2005-02-17 14:11:54 UTC
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
Comment 10 Jeremy Huddleston (RETIRED) gentoo-dev 2005-02-18 03:44:30 UTC
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.
Comment 11 Chris Gianelloni (RETIRED) gentoo-dev 2005-02-18 13:06:52 UTC
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.
Comment 12 Jeremy Huddleston (RETIRED) gentoo-dev 2005-02-18 13:46:03 UTC
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.
Comment 13 Jeremy Huddleston (RETIRED) gentoo-dev 2005-02-19 14:55:40 UTC
*** Bug 82553 has been marked as a duplicate of this bug. ***
Comment 14 Karsten Becker 2005-02-20 02:41:30 UTC
Please reopen. It's not been solved yet. See Bug 82553 for details.
Comment 15 Michel Wendrich 2005-02-20 20:20:52 UTC
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.
Comment 16 Michel Wendrich 2005-02-20 20:21:17 UTC
Created attachment 51745 [details]
config.log of gcc-3.4.3-r1
Comment 17 Jeremy Huddleston (RETIRED) gentoo-dev 2005-02-21 11:19:40 UTC
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
Comment 18 Michel Wendrich 2005-02-21 15:27:36 UTC
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.
Comment 19 Karsten Becker 2005-02-22 00:06:16 UTC
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.
Comment 20 Karsten Becker 2005-02-22 00:42:11 UTC
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.
Comment 21 Jeremy Huddleston (RETIRED) gentoo-dev 2005-02-22 04:08:12 UTC
(1) Fixed.

(2) Yes, it does work.  LD_PRELOAD uses /etc/ld.so.cache.  Also, binutils uses /lib32, and gcc uses ../lib32
Comment 22 Karsten Becker 2005-02-22 09:57:10 UTC
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.
Comment 23 Chris Gianelloni (RETIRED) gentoo-dev 2005-03-25 11:25:13 UTC
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.