[Bug bootstrap/21162] New: Build failure

[Bug bootstrap/21162] New: Build failure

[jdavidb at goreadthebible dot com]

I get a build failure while building stage2 in a bootstrap-lean on Debian Sarge
for sparc on a Sun Blade 100.

I used the following command:
~/gcc-build$ ../gcc-4.0.0/configure --prefix=/usr/local/gnu/gcc/4.0.0 && make
bootstrap-lean check install

The tail end of the build process is as follows.  I can make a transcript of the
entire process if that will help.

stage1/xgcc -Bstage1/ -B/usr/local/gnu/gcc/4.0.0/sparc64-unknown-linux-gnu/bin/
-c   -g -O2 -DIN_GCC   -W -Wall -Wwrite-strings -Wstrict-prototypes
-Wmissing-prototypes -pedantic -Wno-long-long -Wno-variadic-macros
-Wold-style-definition     -DHAVE_CONFIG_H -DGENERATOR_FILE    -I. -Ibuild
-I../../gcc-4.0.0/gcc -I../../gcc-4.0.0/gcc/build
-I../../gcc-4.0.0/gcc/../include -I../../gcc-4.0.0/gcc/../libcpp/include  \
 -o build/errors.o ../../gcc-4.0.0/gcc/errors.c
stage1/xgcc -Bstage1/ -B/usr/local/gnu/gcc/4.0.0/sparc64-unknown-linux-gnu/bin/
  -g -O2 -DIN_GCC   -W -Wall -Wwrite-strings -Wstrict-prototypes
-Wmissing-prototypes -pedantic -Wno-long-long -Wno-variadic-macros
-Wold-style-definition     -DHAVE_CONFIG_H -DGENERATOR_FILE  -o build/genmodes \
 build/genmodes.o build/errors.o
../build-sparc64-unknown-linux-gnu/libiberty/libiberty.a
/usr/bin/ld: warning: sparc architecture of input file
`../build-sparc64-unknown-linux-gnu/libiberty/libiberty.a(hashtab.o)' is
incompatible with sparc:v9 output
/usr/bin/ld: warning: sparc architecture of input file
`../build-sparc64-unknown-linux-gnu/libiberty/libiberty.a(xmalloc.o)' is
incompatible with sparc:v9 output
/usr/bin/ld: warning: sparc architecture of input file
`../build-sparc64-unknown-linux-gnu/libiberty/libiberty.a(xstrdup.o)' is
incompatible with sparc:v9 output
/usr/bin/ld: warning: sparc architecture of input file
`../build-sparc64-unknown-linux-gnu/libiberty/libiberty.a(xexit.o)' is
incompatible with sparc:v9 output
../build-sparc64-unknown-linux-gnu/libiberty/libiberty.a(hashtab.o)(.text+0x3b0):
In function `find_empty_slot_for_expand':
../../../gcc-4.0.0/libiberty/hashtab.c:256: undefined reference to `__muldi3'
../build-sparc64-unknown-linux-gnu/libiberty/libiberty.a(hashtab.o)(.text+0x3cc):../../../gcc-4.0.0/libiberty/hashtab.c:261:
undefined reference to `.umul'
../build-sparc64-unknown-linux-gnu/libiberty/libiberty.a(hashtab.o)(.text+0x40c):../../../gcc-4.0.0/libiberty/hashtab.c:256:
undefined reference to `__muldi3'
../build-sparc64-unknown-linux-gnu/libiberty/libiberty.a(hashtab.o)(.text+0x42c):../../../gcc-4.0.0/libiberty/hashtab.c:261:
undefined reference to `.umul'
../build-sparc64-unknown-linux-gnu/libiberty/libiberty.a(hashtab.o)(.text+0x624):
In function `htab_find_with_hash':
../../../gcc-4.0.0/libiberty/hashtab.c:256: undefined reference to `__muldi3'
../build-sparc64-unknown-linux-gnu/libiberty/libiberty.a(hashtab.o)(.text+0x640):../../../gcc-4.0.0/libiberty/hashtab.c:261:
undefined reference to `.umul'
../build-sparc64-unknown-linux-gnu/libiberty/libiberty.a(hashtab.o)(.text+0x6bc):../../../gcc-4.0.0/libiberty/hashtab.c:256:
undefined reference to `__muldi3'
../build-sparc64-unknown-linux-gnu/libiberty/libiberty.a(hashtab.o)(.text+0x6dc):../../../gcc-4.0.0/libiberty/hashtab.c:261:
undefined reference to `.umul'
../build-sparc64-unknown-linux-gnu/libiberty/libiberty.a(hashtab.o)(.text+0x7b4):
In function `htab_find_slot_with_hash':
../../../gcc-4.0.0/libiberty/hashtab.c:256: undefined reference to `__muldi3'
../build-sparc64-unknown-linux-gnu/libiberty/libiberty.a(hashtab.o)(.text+0x7d0):../../../gcc-4.0.0/libiberty/hashtab.c:261:
undefined reference to `.umul'
../build-sparc64-unknown-linux-gnu/libiberty/libiberty.a(hashtab.o)(.text+0x854):../../../gcc-4.0.0/libiberty/hashtab.c:256:
undefined reference to `__muldi3'
../build-sparc64-unknown-linux-gnu/libiberty/libiberty.a(hashtab.o)(.text+0x874):../../../gcc-4.0.0/libiberty/hashtab.c:261:
undefined reference to `.umul'
../build-sparc64-unknown-linux-gnu/libiberty/libiberty.a(xmalloc.o)(.text+0x124):
In function `xcalloc':
../../../gcc-4.0.0/libiberty/xmalloc.c:161: undefined reference to `.umul'
collect2: ld returned 1 exit status
make[2]: *** [build/genmodes] Error 1
make[2]: Leaving directory `/home/gnu/gcc-build/gcc'
make[1]: *** [stage2_build] Error 2
make[1]: Leaving directory `/home/gnu/gcc-build/gcc'
make: *** [bootstrap-lean] Error 2

I was previously getting a similar error when trying to build gcc 3.4.3 in the
same environment.

I've got GNU as version 2.15, GNU ld version 2.15 (I presume this is all the
same version number for binutils).  Will provide additional info upon request.

-- 
           Summary: Build failure
           Product: gcc
           Version: 4.0.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P2
         Component: bootstrap
        AssignedTo: unassigned at gcc dot gnu dot org
        ReportedBy: jdavidb at goreadthebible dot com
                CC: gcc-bugs at gcc dot gnu dot org
 GCC build triplet: sparc64-unknown-linux-gnu
  GCC host triplet: sparc64-unknown-linux-gnu
GCC target triplet: sparc64-unknown-linux-gnu


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21162

[Bug bootstrap/21162] Build failure

[jdavidb at goreadthebible dot com]

------- Additional Comments From jdavidb at goreadthebible dot com  2005-04-22 15:15 -------
The version of gcc I am using to bootstrap from is 3.3.5.

-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21162

[Bug bootstrap/21162] Build failure

[pinskia at gcc dot gnu dot org]

------- Additional Comments From pinskia at gcc dot gnu dot org  2005-04-22 15:55 -------

/usr/bin/ld: warning: sparc architecture of input file
`../build-sparc64-unknown-linux-gnu/libiberty/libiberty.a(hashtab.o)' is
incompatible with sparc:v9 output

This means that you are building a sparc 64 bit but have building orginaly with a sparc 32bit compiler. 

So this is invalid.  Read the installation instructions, I think there might be something there about this.
If there is not, here is how to do this:

configure --target=sparc-linux-gnu --host=sparc-linux-gnu --build=sparc-linux-gnu 
otherconfigoptions && make bootstrap && make -k check && make install

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |RESOLVED
         Resolution|                            |INVALID


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21162

[Bug bootstrap/21162] Build failure

[jdavidb at goreadthebible dot com]

------- Additional Comments From jdavidb at goreadthebible dot com  2005-04-22 16:00 -------
Thank you, but doesn't this still represent a problem?  Shouldn't config.guess
figure out what kind of compiler to build for my platform without my having to
tell it?

I checked and there's nothing in the installation instructions about it. 
Perhaps a note could be added to the effect that some (or all?)
sparc64-unknown-linux-gnu users will need to specify the target, host, and build
systems themselves?

-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21162

[Bug bootstrap/21162] Build failure

[jdavidb at goreadthebible dot com]

------- Additional Comments From jdavidb at goreadthebible dot com  2005-04-22 17:02 -------
For that matter, if one cannot build the 64 bit compiler with the stock compiler
on Debian sparc64-unknown-linux-gnu, how does one build this compiler?

-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21162

[Bug bootstrap/21162] Build failure

[pinskia at gcc dot gnu dot org]

------- Additional Comments From pinskia at gcc dot gnu dot org  2005-04-22 17:24 -------
(In reply to comment #4)
> For that matter, if one cannot build the 64 bit compiler with the stock compiler
> on Debian sparc64-unknown-linux-gnu, how does one build this compiler?

You build a cross compiler and then a native compiler with the new compiler.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21162

[Bug bootstrap/21162] Build failure

[ebotcazou at gcc dot gnu dot org]

------- Additional Comments From ebotcazou at gcc dot gnu dot org  2005-04-22 17:38 -------
David, could you help here?  I don't think a cross-compiler is necessary.

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |davem at gcc dot gnu dot org
             Status|RESOLVED                    |UNCONFIRMED
         Resolution|INVALID                     |


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21162

[Bug bootstrap/21162] Build failure

[ebotcazou at gcc dot gnu dot org]

------- Additional Comments From ebotcazou at gcc dot gnu dot org  2005-04-22 17:42 -------
> For that matter, if one cannot build the 64 bit compiler with the stock compiler
> on Debian sparc64-unknown-linux-gnu, how does one build this compiler?

That's a Debian problem, the system compiler is probably the 32-bit biarch
compiler, in which case you have to configure with CC="gcc -m64" to bootstrap
the 64-bit compiler.  Does that solve the problem?


-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |ebotcazou at gcc dot gnu dot
                   |                            |org
             Status|UNCONFIRMED                 |WAITING


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21162

[Bug bootstrap/21162] Build failure

[jdavidb at goreadthebible dot com]

------- Additional Comments From jdavidb at goreadthebible dot com  2005-04-22 17:50 -------
(In reply to comment #7)
> > For that matter, if one cannot build the 64 bit compiler with the stock compiler
> > on Debian sparc64-unknown-linux-gnu, how does one build this compiler?
> 
> That's a Debian problem, the system compiler is probably the 32-bit biarch
> compiler, in which case you have to configure with CC="gcc -m64" to bootstrap
> the 64-bit compiler.  Does that solve the problem?

  Well, for my purposes, I have chosen to solve the problem by building with the
options as specified in Andrew's reply.

  I can probably run a test for you if you want, using the options you've
mentioned.  But shouldn't something in configure automatically detect "we're
building the 64-bit compiler (by default because of platform), but the compiler
we have is 32-bit, and that requires we tack on some additional options to build"?

  Basically, what I wanted is to stick a fresh "default" gcc 4.0 in
/usr/local/gnu/gcc/4.0.0 .  Whether it's 32 bit or 64 bit is immaterial to me.

  I see how Debian is causing the problem, though if they are using a 32 bit
compiler on a 64 bit platform.  But I would think gcc configure should work
around that.

  I'll check with CC="gcc -m64" ./configure and report back what I get.

-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21162

[Bug bootstrap/21162] Build failure

[davem at gcc dot gnu dot org]

------- Additional Comments From davem at gcc dot gnu dot org  2005-04-22 18:08 -------
Yes, it should just "work".  And it would have if you:

1) Make sure /lib64/libc.so.6 is installed.
2) Delete the file /etc/disable_64_gcc

Then gcc would output 64-bit code by default when the
"uname" command outputs "sparc64".  You could then simply
run "sparc32 bash" to get an environment where uname outputs
plain "sparc" and this causes the Debian gcc to output 32-bit
code by default.

We plan on adding similar logic to the compiler driver itself.

I totally agree with you that when "uname" outputs "sparc64"
the compiler on the system should be outputting 64-bit code
by default which is what many (not just gcc's) configure
scripts and build trees expect.

Since this problem has to do with Debian's gcc behavior and
not with a gcc proper bug per-se, I'm closing this as invalid.


-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|WAITING                     |RESOLVED
         Resolution|                            |INVALID


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21162

[Bug bootstrap/21162] Build failure

[jdavidb at goreadthebible dot com]

------- Additional Comments From jdavidb at goreadthebible dot com  2005-04-22 18:13 -------
(In reply to comment #7)
> > For that matter, if one cannot build the 64 bit compiler with the stock compiler
> > on Debian sparc64-unknown-linux-gnu, how does one build this compiler?
> 
> That's a Debian problem, the system compiler is probably the 32-bit biarch
> compiler, in which case you have to configure with CC="gcc -m64" to bootstrap
> the 64-bit compiler.  Does that solve the problem?

  Still solving my problem as described earlier, but as a test I tried:
~/gcc-64-build$ CC="gcc -m64" ../gcc-4.0.0/configure
--prefix=/usr/local/gnu/gcc/4.0.0 && make bootstrap-lean

  ... and the output ended with:
checking for sparc64-unknown-linux-gnu-ar... no
checking for ar... ar
checking for sparc64-unknown-linux-gnu-ranlib... no
checking for ranlib... ranlib
checking for sparc64-unknown-linux-gnu-gcc... gcc -m64
checking for C compiler default output file name... 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: *** [configure-build-libiberty] Error 1




-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21162

[Bug bootstrap/21162] Build failure

[jdavidb at goreadthebible dot com]

------- Additional Comments From jdavidb at goreadthebible dot com  2005-04-22 18:15 -------
(In reply to comment #9)
> Yes, it should just "work".  And it would have if you:
> 
> 1) Make sure /lib64/libc.so.6 is installed.
> 2) Delete the file /etc/disable_64_gcc
> 
> Then gcc would output 64-bit code by default when the
> "uname" command outputs "sparc64".  You could then simply
> run "sparc32 bash" to get an environment where uname outputs
> plain "sparc" and this causes the Debian gcc to output 32-bit
> code by default.
> 
> We plan on adding similar logic to the compiler driver itself.
> 
> I totally agree with you that when "uname" outputs "sparc64"
> the compiler on the system should be outputting 64-bit code
> by default which is what many (not just gcc's) configure
> scripts and build trees expect.
> 
> Since this problem has to do with Debian's gcc behavior and
> not with a gcc proper bug per-se, I'm closing this as invalid.

  Thanks for the additional information.  I'm in uncharted waters for me
personally with the mixed 32/64 bit environment.

  Sounds like the preferred solution, at present, is to run
$ sparc32 ../gcc-4.0.0/configure ...

  Someone might add a note to the docs along these lines:
"If you are running Debian GNU/Linux for Sparc and you 'just want a compiler,'
you will probably need to set up a 32-bit sparc environment when you run
configure, as follows:
$ sparc32 ../gcc-4.0.0/configure ..."

-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21162

[Bug bootstrap/21162] Build failure

[davem at gcc dot gnu dot org]

------- Additional Comments From davem at gcc dot gnu dot org  2005-04-22 18:21 -------
Right, it can't compile a test program with "-m64" because the
/lib64/libc.so.6 package is not installed.

Also, when you use "sparc32" you should use it to create a
complete execution environment with "sparc32 bash" or whatever
shell you use.  You need to be in that environment when you
invoke the make, not just when you run the configure scripts.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21162

[Bug bootstrap/21162] Build failure

[jdavidb at goreadthebible dot com]

------- Additional Comments From jdavidb at goreadthebible dot com  2005-04-22 18:25 -------
(In reply to comment #12)
> Right, it can't compile a test program with "-m64" because the
> /lib64/libc.so.6 package is not installed.

  Strangely, I do seem to have that file installed.  But I also have the
/etc/disable_64_gcc file you mentioned earlier.

> Also, when you use "sparc32" you should use it to create a
> complete execution environment with "sparc32 bash" or whatever
> shell you use.  You need to be in that environment when you
> invoke the make, not just when you run the configure scripts.

  Oh, yes.  I'm used to running it all on one command line with && or ; but that
wouldn't work because the sparc32 would only apply to the first command.  Thanks
for pointing that out.

  Trying to figure out if I should cancel my other build that is running at the
moment, where I specified the host/target manually.

Thanks.

-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21162

[Bug bootstrap/21162] Build failure

[davem at gcc dot gnu dot org]

------- Additional Comments From davem at gcc dot gnu dot org  2005-04-22 18:27 -------
You may with to restart your build with the correct environment
setup, just to be safe.  Depending upon what you've enabled
it can take a long time :-)

Yes, the /etc/disable_64_gcc file is what prevents gcc from
outputting 64-bit code by default.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21162