[Bug c/33598] gcc 4.2.1 ignores GNU ld on Solaris 9
--- Comment #16 from dhaliK at jla dot rutgers dot edu 2007-10-23 22:07 --- 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. -- dhaliK at jla dot rutgers dot edu changed: What|Removed |Added Status|WAITING |UNCONFIRMED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33598
[Bug c/33598] gcc 4.2.1 ignores GNU ld on Solaris 9
--- Comment #17 from ebotcazou at gcc dot gnu dot org 2007-10-24 05:26 --- 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. -- ebotcazou at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33598
[Bug c/33598] gcc 4.2.1 ignores GNU ld on Solaris 9
--- Comment #1 from ebotcazou at gcc dot gnu dot org 2007-09-30 09:09 --- 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? -- ebotcazou at gcc dot gnu dot org changed: What|Removed |Added CC||ebotcazou at gcc dot gnu dot ||org Status|UNCONFIRMED |WAITING Summary|gcc 4.2.1 ignores GNU LD in |gcc 4.2.1 ignores GNU ld on |Solaris 9 |Solaris 9 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33598
[Bug c/33598] gcc 4.2.1 ignores GNU ld on Solaris 9
--- Comment #2 from pinskia at gcc dot gnu dot org 2007-09-30 09:22 --- Also try with --with-gnu-ld/--with-gnu-as. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33598
[Bug c/33598] gcc 4.2.1 ignores GNU ld on Solaris 9
--- Comment #3 from pinskia at gcc dot gnu dot org 2007-09-30 09:26 --- 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? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33598
[Bug c/33598] gcc 4.2.1 ignores GNU ld on Solaris 9
--- Comment #4 from ebotcazou at gcc dot gnu dot org 2007-09-30 12:58 --- 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. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33598
[Bug c/33598] gcc 4.2.1 ignores GNU ld on Solaris 9
--- Comment #5 from dhaliK at jla dot rutgers dot edu 2007-09-30 14:12 --- $ /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. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33598
[Bug c/33598] gcc 4.2.1 ignores GNU ld on Solaris 9
--- Comment #6 from ebotcazou at gcc dot gnu dot org 2007-09-30 14:27 --- 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)? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33598
[Bug c/33598] gcc 4.2.1 ignores GNU ld on Solaris 9
--- 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? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33598
Re: [Bug c/33598] gcc 4.2.1 ignores GNU ld on Solaris 9
On 30 Sep 2007 14:32:32 -, ebotcazou at gcc dot gnu dot org [EMAIL PROTECTED] 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.
[Bug c/33598] gcc 4.2.1 ignores GNU ld on Solaris 9
--- Comment #8 from pinskia at gmail dot com 2007-09-30 16:58 --- Subject: Re: gcc 4.2.1 ignores GNU ld on Solaris 9 On 30 Sep 2007 14:32:32 -, ebotcazou at gcc dot gnu dot org [EMAIL PROTECTED] 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. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33598
[Bug c/33598] gcc 4.2.1 ignores GNU ld on Solaris 9
--- Comment #9 from ebotcazou at gcc dot gnu dot org 2007-09-30 17:00 --- nope two dots. Yes, that's precisely why I said source gcc and not source. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33598
[Bug c/33598] gcc 4.2.1 ignores GNU ld on Solaris 9
--- Comment #10 from dhaliK at jla dot rutgers dot edu 2007-09-30 17:08 --- 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. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33598
[Bug c/33598] gcc 4.2.1 ignores GNU ld on Solaris 9
--- Comment #11 from ebotcazou at gcc dot gnu dot org 2007-09-30 17:51 --- 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? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33598
[Bug c/33598] gcc 4.2.1 ignores GNU ld on Solaris 9
--- Comment #12 from dhaliK at jla dot rutgers dot edu 2007-09-30 18:12 --- 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 ;) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33598
[Bug c/33598] gcc 4.2.1 ignores GNU ld on Solaris 9
--- Comment #13 from ebotcazou at gcc dot gnu dot org 2007-09-30 18:30 --- 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. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33598
[Bug c/33598] gcc 4.2.1 ignores GNU ld on Solaris 9
--- Comment #14 from dhaliK at jla dot rutgers dot edu 2007-09-30 18:40 --- 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. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33598
[Bug c/33598] gcc 4.2.1 ignores GNU ld on Solaris 9
--- Comment #15 from ebotcazou at gcc dot gnu dot org 2007-09-30 18:45 --- 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. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33598
