the current trunk doesn't boostrap in multilib configuration: single-threaded build ends with: (...) Adding multilib support to Makefile in ../../zlib multidirs=32 with_multisubdir= Running configure in multilib subdirs 32 pwd: /home/users/pluto/src/gcc/trunk/BUILDDIR/zlib Running configure in multilib subdir 32 pwd: /home/users/pluto/src/gcc/trunk/BUILDDIR mkdir 32 configure: creating cache ./config.cache checking build system type... x86_64-unknown-linux-gnu checking host system type... x86_64-unknown-linux-gnu checking target system type... x86_64-unknown-linux-gnu checking for a BSD-compatible install... /usr/bin/install -c checking whether build environment is sane... yes checking for x86_64-unknown-linux-gnu-strip... no checking for strip... strip checking for a thread-safe mkdir -p... /bin/mkdir -p checking for gawk... gawk checking whether make sets $(MAKE)... yes checking whether to enable maintainer-specific portions of Makefiles... no checking for x86_64-unknown-linux-gnu-gcc... /home/users/pluto/src/gcc/trunk/BUILDDIR/32/./prev-gcc/xgcc -B/home/users/pluto/src/gcc/trunk/BUILDDIR/32/./prev-gcc/ -B/opt/gcc45/x86_64-unknown-linux-gnu/bin/ -B/opt/gcc45/x86_64-unknown-linux-gnu/bin/ -B/opt/gcc45/x86_64-unknown-linux-gnu/lib/ -isystem /opt/ gcc45/x86_64-unknown-linux-gnu/include -isystem /opt/gcc45/x86_64-unknown-linux-gnu/sys-include -m32 checking for suffix of object files... configure: error: in `/home/users/pluto/src/gcc/trunk/BUILDDIR/32/zlib': configure: error: cannot compute suffix of object files: cannot compile See `config.log' for more details. make[2]: *** [configure-stage2-zlib] Error 1 make[2]: Leaving directory `/home/users/pluto/src/gcc/trunk/BUILDDIR' make[1]: *** [stage2-bubble] Error 2 make[1]: Leaving directory `/home/users/pluto/src/gcc/trunk/BUILDDIR' make: *** [all] Error 2 zlib config.log contains: ../../../zlib/configure: /home/users/pluto/src/gcc/trunk/BUILDDIR/32/./prev-gcc/xgcc: not found $ ./prev-gcc/xgcc -v Using built-in specs. COLLECT_GCC=./prev-gcc/xgcc Target: x86_64-unknown-linux-gnu Configured with: ../configure --prefix=/opt/gcc45 --libdir=/opt/gcc45/lib64 --libexecdir=/opt/gcc45/lib64 --with-slibdir=/opt/gcc45/lib64 --enable-multilib --disable-nls --disable-libgomp --disable-libmudflap --disable-libssp --disable-libstdcxx-pch --disable-shared --with-pic --enable-c99 --enable-long-long --enable-linux-futex --enable-threads=posix --enable-__cxa_atexit --enable-languages=c,c++ --with-long-double-128 --disable-cld Thread model: posix gcc version 4.5.0 20100310 (experimental) (GCC)
I did a bootstrap on x86_64-linux-gnu at revision 157328. zlib here is a host library which means it does not need to be multilibed.
Quoting install.texi: First, we @strong{highly} recommend that GCC be built into a separate directory from the sources which does @strong{not} reside within the source tree. This is how we generally build GCC; building where @var{srcdir} == @var{objdir} should still work, but doesn't get extensive testing; building where @var{objdir} is a subdirectory of @var{srcdir} is unsupported. Your build violates the latter. Please start anew with a freshly(!) unpacked source tree.
(In reply to comment #2) > Quoting install.texi: > > First, we @strong{highly} recommend that GCC be built into a > separate directory from the sources which does @strong{not} reside > within the source tree. This is how we generally build GCC; building > where @var{srcdir} == @var{objdir} should still work, but doesn't > get extensive testing; building where @var{objdir} is a subdirectory > of @var{srcdir} is unsupported. > > Your build violates the latter. Please start anew with a freshly(!) unpacked > source tree. ehhh, you're walking around the real bug :) fresh build inside /tmp/BUILDDIR (sources at ~/src/gcc/trunk) ends with the same error: (...) make[5]: Entering directory `/tmp/BUILDDIR/32/zlib' make[5]: *** No rule to make target `all'. Stop. make[5]: Leaving directory `/tmp/BUILDDIR/32/zlib' make[4]: *** [multi-do] Error 1 make[4]: Leaving directory `/tmp/BUILDDIR/zlib' make[3]: *** [all-multi] Error 2 make[3]: Leaving directory `/tmp/BUILDDIR/zlib' make[2]: *** [all-stage2-zlib] Error 2 make[2]: Leaving directory `/tmp/BUILDDIR' make[1]: *** [stage2-bubble] Error 2 make[1]: Leaving directory `/tmp/BUILDDIR' make: *** [all] Error 2 /tmp/BUILDDIR/32/zlib/config.log: /home/users/pluto/src/gcc/trunk/zlib/configure: /tmp/BUILDDIR/32/./prev-gcc/xgcc: not found
Did you 'rm -rf ~/src/gcc/trunk' and create that directory anew?
(In reply to comment #4) > Did you 'rm -rf ~/src/gcc/trunk' and create that directory anew? no, what for? svn status reports no unversioned files in trunk directory.
Subject: Re: multilib bootstrap broken. Sent from my iPhone On Mar 11, 2010, at 10:11 AM, "pluto at agmk dot net" <gcc-bugzilla@gcc.gnu.org > wrote: > > > ------- Comment #5 from pluto at agmk dot net 2010-03-11 18:11 > ------- > (In reply to comment #4) >> Did you 'rm -rf ~/src/gcc/trunk' and create that directory anew? > > no, what for? svn status reports no unversioned files in trunk > directory. Svn status does not report .o files normally. > > > -- > > > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43328 >
(In reply to comment #6) > > no, what for? svn status reports no unversioned files in trunk > > directory. > > Svn status does not report .o files normally. my ~/.subversion/config has custom global-ignores and i know what it ignores. [~/src/gcc/trunk]$ touch x.o [~/src/gcc/trunk]$ svn st ? x.o the trunk directory is a clean checkout and bootsrap inside /tmp/BUILDDIR fails.
(In reply to comment #5) > (In reply to comment #4) > > Did you 'rm -rf ~/src/gcc/trunk' and create that directory anew? > > no, what for? svn status reports no unversioned files in trunk directory. Please allow me to be dense, and ask you to *please* rm -rf the source tree and check it out anew. Just do it. And then, when your build still fails, report the revision you're building, the exact configure command line you've used, and the error that you get, starting from the *first* error message, not the last one. Thanks. A simple extra existing directory in the source tree may be the reason for the failure, but I'm not going to search the PR database for which one it was, now, and I don't remember off-hand.
Created attachment 20087 [details] build log for very very clean source tree.
Created attachment 20089 [details] build script.
(In reply to comment #8) > (In reply to comment #5) > > (In reply to comment #4) > > > Did you 'rm -rf ~/src/gcc/trunk' and create that directory anew? > > > > no, what for? svn status reports no unversioned files in trunk directory. > > Please allow me to be dense, and ask you to *please* rm -rf the source > tree and check it out anew. Just do it. And then, when your build still > fails, report the revision you're building, the exact configure command > line you've used, and the error that you get, starting from the *first* > error message, not the last one. Thanks. 'rm -rf' done, checkout done, 'svn pd svn:ignore trunk -R' done, build log attached, build script attached, 'svn st' reports clean source tree.
Thanks. I can reproduce a spurious toplevel-build/32/zlib directory when --enable-multilib is passed explicitly to toplevel configure. Workaround is to not pass --enable-multilib, multilibs are enabled by default. Will fix, I guess, even if install.texi does document that only --disable-multilib may be needed. However, I cannot reproduce a build error. The build completes for me with both the options from comment #10 and the initial report.
BTW, the actual bug is that, if --enable-multilib is passed explicitly, it will wrongly propagate to build_configargs and host_configargs and not only to target_configargs.
Patch at <http://gcc.gnu.org/ml/gcc-patches/2010-03/msg00509.html>.
Subject: Bug 43328 Author: rwild Date: Wed Mar 31 05:44:30 2010 New Revision: 157851 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=157851 Log: Fix toplevel configure --enable-multilib handling. /: PR bootstrap/43328 * configure.ac: Do not pass --enable-multilib nor --disable-multilib in baseargs. Accept explicitly passed --enable_multilib. * configure: Regenerate. Modified: trunk/ChangeLog trunk/configure trunk/configure.ac
Fixed? But caused PR43615. --disable-multilib no longer works.
Subject: Bug 43328 Author: rwild Date: Thu Apr 1 16:32:38 2010 New Revision: 157916 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=157916 Log: /: PR bootstrap/43615 PR bootstrap/43328 Revert: 2010-03-31 Ralf Wildenhues <Ralf.Wildenhues@gmx.de> * configure.ac: Do not pass --enable-multilib nor --disable-multilib in baseargs. Accept explicitly passed --enable_multilib. * configure: Regenerate. Modified: trunk/ChangeLog trunk/configure trunk/configure.ac
(In reply to comment #17) > Subject: Bug 43328 > > Author: rwild > Date: Thu Apr 1 16:32:38 2010 > New Revision: 157916 > > URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=157916 > Log: > /: > PR bootstrap/43615 > PR bootstrap/43328 > > Revert: > > 2010-03-31 Ralf Wildenhues <Ralf.Wildenhues@gmx.de> > > * configure.ac: Do not pass --enable-multilib nor > --disable-multilib in baseargs. Accept explicitly passed > --enable_multilib. > * configure: Regenerate. > > Modified: > trunk/ChangeLog > trunk/configure > trunk/configure.ac what's the current status of the --{dis/en}able-multilib switches? afaics at least the --disable-multilib is ignored on 4.5/4.6 svn head.
(In reply to comment #18) > what's the current status of the --{dis/en}able-multilib switches? As far as I know that of from before this PR: enabled multilib is the default (if you don't pass any option), and you can disable that by passing --disable-multilib. So the only thing to remember is not to pass --enable-multilib explicitly. > afaics at least the --disable-multilib is ignored on 4.5/4.6 svn head. That would seem to be a new regression; please open a new PR for it, including full details as usual for a PR. Thanks.
(In reply to comment #19) > (In reply to comment #18) > > what's the current status of the --{dis/en}able-multilib switches? > > As far as I know that of from before this PR: enabled multilib is the default > (if you don't pass any option), and you can disable that by passing > --disable-multilib. So the only thing to remember is not to pass > --enable-multilib explicitly. > > > afaics at least the --disable-multilib is ignored on 4.5/4.6 svn head. > > That would seem to be a new regression; please open a new PR for it, including > full details as usual for a PR. Thanks. ooops, false alarm. it was a typo (mutlilib) in my scripts.
Building gcc 4.6.2 as a cross-compiler on ix86 targetting arm-elf fails for me w/ --enable-multilib explicitly passed on, w/ zlib barking about trying to compile a 64-bit version. gcc 4.6.1 used to work w/ same directives, so I suspect I'm seeing a regression. removing --enable-multilib from args passed to gcc seems to make the issue go away.
Created attachment 28102 [details] gcc-fix-multib-hostargs.patch This patch fixes the bug by only adding --*-multilib options to baseargs and not tbaseargs.
Sorry, I inverted my previous comment, should be: > This patch fixes the bug by only adding --*-multilib options to tbaseargs and not baseargs. ie, "tbaseargs" & "baseargs" were swapped
Fixed for GCC 9 by r9-1316.
*** Bug 57990 has been marked as a duplicate of this bug. ***
*** Bug 61104 has been marked as a duplicate of this bug. ***