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.
The version of gcc I am using to bootstrap from is 3.3.5.
/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
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?
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?
(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.
David, could you help here? I don't think a cross-compiler is necessary.
> 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?
(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.
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.
(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
(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 ..."
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.
(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.
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.