Bug 43328 - multilib bootstrap broken.
Summary: multilib bootstrap broken.
Status: NEW
Alias: None
Product: gcc
Classification: Unclassified
Component: bootstrap (show other bugs)
Version: 4.5.0
: P3 normal
Target Milestone: ---
Assignee: Not yet assigned to anyone
URL:
Keywords:
Depends on:
Blocks: 43615
  Show dependency treegraph
 
Reported: 2010-03-10 22:33 UTC by Pawel Sikora
Modified: 2012-08-29 23:49 UTC (History)
5 users (show)

See Also:
Host: x86_64-gnu-linux
Target: x86_64-gnu-linux
Build: x86_64-gnu-linux
Known to work: 4.3.5, 4.4.4
Known to fail: 4.5.0
Last reconfirmed: 2010-03-12 18:09:42


Attachments
build log for very very clean source tree. (38.71 KB, application/octet-stream)
2010-03-11 19:28 UTC, Pawel Sikora
Details
build script. (376 bytes, text/plain)
2010-03-11 19:29 UTC, Pawel Sikora
Details
gcc-fix-multib-hostargs.patch (305 bytes, patch)
2012-08-29 23:47 UTC, Cody Schafer
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Pawel Sikora 2010-03-10 22:33:21 UTC
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)
Comment 1 Andrew Pinski 2010-03-10 22:37:29 UTC
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.
Comment 2 Ralf Wildenhues 2010-03-11 15:46:37 UTC
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.
Comment 3 Pawel Sikora 2010-03-11 16:02:24 UTC
(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
Comment 4 Ralf Wildenhues 2010-03-11 16:06:46 UTC
Did you 'rm -rf ~/src/gcc/trunk' and create that directory anew?
Comment 5 Pawel Sikora 2010-03-11 18:11:07 UTC
(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.
Comment 6 pinskia@gmail.com 2010-03-11 18:15:35 UTC
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
>
Comment 7 Pawel Sikora 2010-03-11 18:21:19 UTC
(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.
Comment 8 Ralf Wildenhues 2010-03-11 18:33:15 UTC
(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.
Comment 9 Pawel Sikora 2010-03-11 19:28:25 UTC
Created attachment 20087 [details]
build log for very very clean source tree.
Comment 10 Pawel Sikora 2010-03-11 19:29:10 UTC
Created attachment 20089 [details]
build script.
Comment 11 Pawel Sikora 2010-03-11 19:33:24 UTC
(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.
Comment 12 Ralf Wildenhues 2010-03-12 18:09:42 UTC
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.
Comment 13 Ralf Wildenhues 2010-03-12 18:10:49 UTC
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.
Comment 14 Ralf Wildenhues 2010-03-16 07:56:50 UTC
Patch at <http://gcc.gnu.org/ml/gcc-patches/2010-03/msg00509.html>.
Comment 15 Ralf Wildenhues 2010-03-31 05:44:47 UTC
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

Comment 16 Richard Biener 2010-04-01 13:17:19 UTC
Fixed?  But caused PR43615.  --disable-multilib no longer works.
Comment 17 Ralf Wildenhues 2010-04-01 16:32:55 UTC
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

Comment 18 Pawel Sikora 2010-11-21 08:23:27 UTC
(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.
Comment 19 Ralf Wildenhues 2010-11-21 08:28:07 UTC
(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.
Comment 20 Pawel Sikora 2010-11-21 08:41:34 UTC
(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.
Comment 21 Alexandre Pereira Nunes 2011-10-30 11:20:11 UTC
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.
Comment 22 Cody Schafer 2012-08-29 23:47:24 UTC
Created attachment 28102 [details]
gcc-fix-multib-hostargs.patch

This patch fixes the bug by only adding --*-multilib options to baseargs and not tbaseargs.
Comment 23 Cody Schafer 2012-08-29 23:49:04 UTC
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