We recently upgraded to 4.2.1 and noticed an immediate issue. After compiling gcc for sparcv9 and specifically setting --with-ld=/usr/local/gnu/bin/ld, whenever gcc actually runs it internally calls the Sun linker and therefore dies with unknown options. A simple "hello world" refuses to build because of bad LD options. Setting LD= seems to have little effect. I'm pasting a -v output of it below. Note I was using g++ here because that was handy, but it is the same for eitehr gcc or g++: /usr/local/bin/sparcv9/g++ -v hello.cpp Using built-in specs. Target: sparc-sun-solaris2.9 Configured with: ../configure --enable-shared --enable-threads --with-ld=/usr/local/gnu/bin/ld --with-as=/usr/local/gnu/bin/as --disable-multilib --disable-libgcj --disable-libffi --disable-libjava --disable-nls --bindir=/usr/local/bin/sparcv9 --libdir=/usr/local/lib/sparcv9 Thread model: posix gcc version 4.2.1 /usr/local/libexec/gcc/sparc-sun-solaris2.9/4.2.1/cc1plus -quiet -v -D__sparcv8 hello.cpp -quiet -dumpbase hello.cpp -mcpu=v9 -auxbase hello -version -o /var/tmp//ccM6WkGY.s ignoring nonexistent directory "NONE/include" ignoring nonexistent directory "/usr/local/lib/gcc/sparc-sun-solaris2.9/4.2.1/../../../../sparc-sun-solaris2.9/include" #include "..." search starts here: #include <...> search starts here: /usr/local/lib/gcc/sparc-sun-solaris2.9/4.2.1/../../../../include/c++/4.2.1 /usr/local/lib/gcc/sparc-sun-solaris2.9/4.2.1/../../../../include/c++/4.2.1/sparc-sun-solaris2.9 /usr/local/lib/gcc/sparc-sun-solaris2.9/4.2.1/../../../../include/c++/4.2.1/backward /usr/local/include /usr/local/lib/gcc/sparc-sun-solaris2.9/4.2.1/include /usr/include End of search list. GNU C++ version 4.2.1 (sparc-sun-solaris2.9) compiled by GNU C version 4.2.1. GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072 Compiler executable checksum: 7f9cd0c7cc891b25f4cbce210dc67670 /usr/local/gnu/bin/as -V -Qy -s -xarch=v8plus -o /var/tmp//ccZD9lJS.o /var/tmp//ccM6WkGY.s GNU assembler version 2.17 (sparc-sun-solaris2.9) using BFD version 2.17 /usr/local/libexec/gcc/sparc-sun-solaris2.9/4.2.1/collect2 -V -Y P,/usr/ccs/lib:/usr/lib -rpath-link /usr/lib -Qy /usr/local/lib/sparcv9/gcc/sparc-sun-solaris2.9/4.2.1/crt1.o /usr/local/lib/sparcv9/gcc/sparc-sun-solaris2.9/4.2.1/crti.o /usr/ccs/lib/values-Xa.o /usr/local/lib/sparcv9/gcc/sparc-sun-solaris2.9/4.2.1/crtbegin.o -L/usr/local/lib/sparcv9/gcc/sparc-sun-solaris2.9/4.2.1 -L/usr/ccs/lib -L/usr/local/lib/sparcv9/gcc/sparc-sun-solaris2.9/4.2.1/../../.. /var/tmp//ccZD9lJS.o -lstdc++ -lm -lgcc_s -lgcc -lc -lgcc_s -lgcc -lc /usr/local/lib/sparcv9/gcc/sparc-sun-solaris2.9/4.2.1/crtend.o /usr/local/lib/sparcv9/gcc/sparc-sun-solaris2.9/4.2.1/crtn.o ld: Software Generation Utilities - Solaris Link Editors: 5.9-1.390 ld: fatal: option -dn and -P are incompatible ld: fatal: Flags processing errors collect2: ld returned 1 exit status
> We recently upgraded to 4.2.1 and noticed an immediate issue. After compiling > gcc for sparcv9 and specifically setting --with-ld=/usr/local/gnu/bin/ld, It is as though /usr/local/gnu/bin/ld was not invoked at all. Could you post the output of '/usr/local/gnu/bin/ld --version'? Did you bootstrap or build the compiler?
Also try with --with-gnu-ld/--with-gnu-as.
Also this does not make sense as bootstrap should have failed if gnu ld was not used. (In reply to comment #1) > It is as though /usr/local/gnu/bin/ld was not invoked at all. Could you post > the output of '/usr/local/gnu/bin/ld --version'? > Did you bootstrap or build the compiler? Since it is 4.2.1, you can tell it was bootstrapped by the non use of --disable-bootstrap :). The main question I have is how bootstrapped worked but not the installed g++. Did you change something after install? Like delete the GNU ld?
> Also try with --with-gnu-ld/--with-gnu-as. These switches are useless with --with-ld/--with-as. Moreover, the compiler is apparently already configured for GNU ld.
$ /usr/local/gnu/bin/ld --version GNU ld version 2.17 Copyright 2005 Free Software Foundation, Inc. This program is free software; you may redistribute it under the terms of the GNU General Public License. This program has absolutely no warranty. I'm thinking -with-gnu-ld would fail anyways because since this is Solaris we have our GNU binaries in a non-standard path, hence why we use --with-ld= Two questions: Is --enable-bootstrap the default action and *should* I be explicitly enabling bootstrap with this type of setup? I'm also going to try building it with the Sun as and ld. In the same rpm build we do a second normal sparc build with the only difference being its use of the Sun tools, and that build compiles everything just fine. Even though my predecessor alreayd set it up that way, I'm not sure if the GNU ld is specifically needed for sparcv9 since Sun ld works fine on normal sparc builds. Either way... if it's ignoring the explicit declaration of GNU ld and using Sun ld, maybe setting it to Sun ld from the start will have a better result.
> Two questions: Is --enable-bootstrap the default action and *should* I > be explicitly enabling bootstrap with this type of setup? Yes, --enable-bootstrap is the default with 4.2.x so you only need to type 'make' or 'gmake' to bootstrap the compiler. As Andrew said, there is some mystery here: if the compiler cannot find /usr/local/gnu/bin/ld, it should never have been able to bootstrap itself. Could you verify that you have 3 compilers in the build directory, one for each stage of the 3-stage bootstrap? If they are there, could you try to reproduce the problem with them (instead of with the installed compiler)?
> Configured with: ../configure --enable-shared --enable-threads > --with-ld=/usr/local/gnu/bin/ld --with-as=/usr/local/gnu/bin/as > --disable-multilib --disable-libgcj --disable-libffi --disable-libjava > --disable-nls --bindir=/usr/local/bin/sparcv9 --libdir=/usr/local/lib/sparcv9 > Thread model: posix > gcc version 4.2.1 Btw, aren't you building in the source gcc directory?
Subject: Re: gcc 4.2.1 ignores GNU ld on Solaris 9 On 30 Sep 2007 14:32:32 -0000, ebotcazou at gcc dot gnu dot org <gcc-bugzilla@gcc.gnu.org> wrote: > > > ------- Comment #7 from ebotcazou at gcc dot gnu dot org 2007-09-30 14:32 ------- > > Configured with: ../configure --enable-shared --enable-threads > > --with-ld=/usr/local/gnu/bin/ld --with-as=/usr/local/gnu/bin/as > > --disable-multilib --disable-libgcj --disable-libffi --disable-libjava > > --disable-nls --bindir=/usr/local/bin/sparcv9 --libdir=/usr/local/lib/sparcv9 > > Thread model: posix > > gcc version 4.2.1 > > Btw, aren't you building in the source gcc directory? nope two dots.
> nope two dots. Yes, that's precisely why I said "source gcc" and not "source".
We build it twice. One for normal sparc (v8+ I believe) and one for sparcv9. The rpm spec file just cd's into gcc and makes a tmp sparc directory... hence the ../configure. It then makes a sparcv9 directory and does the same thing all over. This way one pass with rpmbuild spits out both. I'll get back to you on reproducing it in the build directory since it's still running right now from before... old machine and it doesn't seem to like gmake -j and exits randomly between files :( I'm interested to see if this build with sun as and ld gives the same problem since our normal sparc build doesn't.
> We build it twice. One for normal sparc (v8+ I believe) and one for sparcv9. > The rpm spec file just cd's into gcc and makes a tmp sparc directory... hence > the ../configure. It then makes a sparcv9 directory and does the same thing all > over. This way one pass with rpmbuild spits out both. Note that we specifically warn against configuring the compiler that way: http://gcc.gnu.org/install/configure.html Moreover, what do you call "to build for sparcv9" exactly? In other words, what's the difference between your 2 builds?
Thanks for the subdir heads up, I was not aware of that being an issue. On my next build I'll move it outside the src tree and see if it is happier. As far as sparcv9 goes, the bin and lib dirs obviously have to be different: --bindir=/usr/local/bin/sparcv9 --libdir=/usr/local/lib/sparcv9 as opposed to defaults, but the main differences is the use of: LD_RUN_PATH="/usr/local/lib/sparcv9:/usr/local/lib" rather than the standard /usr/local/lib. We don't want default sparc builds (v8+) looking in sparcv9 and of course sparcv9 should. Actually, while I was looking through the spec for this I found a typo that probably isn't related but could be a problem and should be fixed. In the meantime I'm rerunning the build outside of the src tree at your request. Have you guys had issues in the past with gmake -j or is it just my particular build platform? I wish I could use smp... it would finish a lot faster ;)
> As far as sparcv9 goes, the bin and lib dirs obviously have to be different: > > --bindir=/usr/local/bin/sparcv9 --libdir=/usr/local/lib/sparcv9 > > as opposed to defaults, but the main differences is the use of: > > LD_RUN_PATH="/usr/local/lib/sparcv9:/usr/local/lib" > > rather than the standard /usr/local/lib. None of these settings will give you a sparcv9 compiler and that could explain your problem. The sparcv9 subdirectory of /lib on Solaris contains 64-bit libraries so you need a 64-bit capable compiler to use them, either the multilib 32-bit sparc-sun-solaris2.9 compiler or the sparc64-sun-solaris2.9 compiler. The configure line you posted will build the non-multilib 32-bit compiler.
> > None of these settings will give you a sparcv9 compiler and that could > explain your problem. > > The sparcv9 subdirectory of /lib on Solaris contains 64-bit libraries so > you need a 64-bit capable compiler to use them, either the multilib 32-bit > sparc-sun-solaris2.9 compiler or the sparc64-sun-solaris2.9 compiler. > > The configure line you posted will build the non-multilib 32-bit compiler. > Hmm that would be a problem! I think what we had in mind was ensuring that our custom 64bit packages (/usr/local/lib/sparcv9) were in the run path, while assuming that /lib/sparcv9 was already there. Sorry for the trouble, you've been a great help, but can you point me in the right direction of a proper 64bit configure, or better yet, a multlib build (than I only have to build it once! :) I know I had experimented trying to get multilib working once already but it never happened. Either way, if it's not possible on solaris at least getting a proper 64bit would be great. Our 32bit seems to work fine.
> Sorry for the trouble, you've been a great help, but can you point me in the > right direction of a proper 64bit configure, or better yet, a multlib build > (than I only have to build it once! :) I know I had experimented trying to get > multilib working once already but it never happened. Either way, if it's not > possible on solaris at least getting a proper 64bit would be great. Our 32bit > seems to work fine. Multilib has worked for ages, just configure without --disable-multilib and without fiddling with --bindir and --libdir.
Ok, so I'm back on the track of what's going on here. I built it with multilib as you said, and it builds 32/64 fine on Solaris, but when it goes to link internally it chokes on the 64-bitness. In other words, gcc looks like it requires gnu ld in order to build 64bit on Solaris and that was why we had been building two flavors of it. One built with gnu ld and one with sun ld. This is what happens: gcc -v -o /usr/local/src/rpm-packages/BUILD/otp_src_R11B-5/bin/sparc-sun-solaris2.9/beam -L/usr/local/lib/sparcv9 -L/usr/local/ssl/lib/sparcv9 -R/usr/local/lib/sparcv9 -R/usr/local/ssl/lib/sparcv9 /usr/local/src/rpm-packages/BUILD/otp_src_R11B-5/erts/emulator/obj/sparc-sun-solaris2.9/opt/plain/erl_main.o Using built-in specs. Target: sparc-sun-solaris2.9 Configured with: ../gcc-4.2.2/configure --enable-shared --enable-threads --with-ld=/usr/ccs/bin/ld --with-as=/usr/ccs/bin/as --disable-libgcj --disable-libffi --disable-libjava --disable-nls Thread model: posix gcc version 4.2.2 /usr/local/libexec/gcc/sparc-sun-solaris2.9/4.2.2/collect2 -V -R/usr/local/lib/sparcv9 -R/usr/local/ssl/lib/sparcv9 -Y P,/usr/ccs/lib:/usr/lib -Qy -o /usr/local/src/rpm-packages/BUILD/otp_src_R11B-5/bin/sparc-sun-solaris2.9/beam /usr/local/lib/gcc/sparc-sun-solaris2.9/4.2.2/crt1.o /usr/local/lib/gcc/sparc-sun-solaris2.9/4.2.2/crti.o /usr/ccs/lib/values-Xa.o /usr/local/lib/gcc/sparc-sun-solaris2.9/4.2.2/crtbegin.o -L/usr/local/lib/sparcv9 -L/usr/local/ssl/lib/sparcv9 -L/usr/local/lib/gcc/sparc-sun-solaris2.9/4.2.2 -L/usr/ccs/lib -L/usr/local/lib/gcc/sparc-sun-solaris2.9/4.2.2/../../.. /usr/local/src/rpm-packages/BUILD/otp_src_R11B-5/erts/emulator/obj/sparc-sun-solaris2.9/opt/plain/erl_main.o -lgcc -lgcc_eh -lc -lgcc -lgcc_eh -lc /usr/local/lib/gcc/sparc-sun-solaris2.9/4.2.2/crtend.o /usr/local/lib/gcc/sparc-sun-solaris2.9/4.2.2/crtn.o ld: Software Generation Utilities - Solaris Link Editors: 5.9-1.390 ld: fatal: file /usr/local/src/rpm-packages/BUILD/otp_src_R11B-5/erts/emulator/obj/sparc-sun-solaris2.9/opt/plain/erl_main.o: wrong ELF class: ELFCLASS64 ld: fatal: File processing errors. No output written to /usr/local/src/rpm-packages/BUILD/otp_src_R11B-5/bin/sparc-sun-solaris2.9/beam You get an ELFCLASS error everytime it links with 64bit. The sun ld that gcc was configured with thinks its being handed a 32bit file by default and chokes on 64bit. I'm assuming gcc has no way of telling it to expect 64bit and thats where it dies. The file I'm showing above had been build with gcc -mcpu=v9 -m64, so it should pass that along, but it doesn't. I'm guess I'm going to have to have two flavors of gcc after all. 64bit with gnu ld and 32bit with sun ld. Is there any chance of getting around this? I tried LD=/usr/local/gnu/bin/ld but it ignore it.
> In other words, gcc looks like it requires gnu ld in order to build 64bit > on Solaris and that was why we had been building two flavors of it. That's wrong. > The file I'm showing above had been build with gcc -mcpu=v9 -m64, so it > should pass that along, but it doesn't. No, it shouldn't, you have to pass -m64 at link time.