On Solaris (and HPUX, other ...) Operating Systems the OS's Manufacturer has their own Linker and recommends it be used for all linking. The OpenSolaris "default gcc" supplied by Sun is: # /usr/sfw/bin/gcc -v Reading specs from /usr/sfw/lib/gcc/i386-pc-solaris2.11/3.4.3/specs Configured with: /builds2/sfwnv-gate/usr/src/cmd/gcc/gcc-3.4.3/configure --prefix=/usr/sfw --with-as=/usr/sfw/bin/gas --with-gnu-as --with-ld=/usr/ccs/bin/ld --without-gnu-ld --enable-languages=c,c++,f77,objc --enable-shared Thread model: posix gcc version 3.4.3 (csl-sol210-3_4-20050802) Note that the "enable-languages" lacks Ada so if you desire to build the Trunk with Ada you would need a different compiler, here is BlastWave's: # /opt/csw/gcc3/bin/gcc -v Reading specs from /opt/csw/gcc3/lib/gcc/i386-pc-solaris2.8/3.4.5/specs Configured with: ../sources/gcc-3.4.5/configure --prefix=/opt/csw/gcc3 --with-local-prefix=/opt/csw --with-gnu-as --with-as=/opt/csw/bin/gas --without-gnu-ld --with-ld=/usr/ccs/bin/ld --enable-threads=posix --enable-shared --enable-multilib --enable-nls --with-included-gettext --with-libiconv-prefix=/opt/csw --with-x --enable-java-awt=xlib --enable-languages=all Thread model: posix gcc version 3.4.5 Note that in both of the commonly available compilers for Solaris the person who built gcc used Sun's linker. It is dated "Nov 19 2008". # /usr/ccs/bin/ld -V ld: Software Generation Utilities - Solaris Link Editors: 5.11-1.1624 While Sun (and other OS Manufacturers) may "recommend" you use their Linker it is not "required" by GNU that you do so. You can use GNU's Linker. If you use GNU's Linker on Solaris then you have slightly newer features from Binutils and you can enable Mudflaps. That might be useful for some. The "BUG" is this: If you compile gcc (using a gcc that uses Sun's Linker) to make a gcc Toolchain that uses GNU's Linker the resulting gcc Toolchain will WORK reasonably well and passes most "make -i check" tests. If you compile gcc (using a gcc that uses GNU's Linker) to make a gcc Toolchain that uses Sun's Linker the resulting gcc Toolchain will WORK reasonably well and passes most "make -i check" tests. This problem seems to start with the configure during the build, little things seem to be getting detected differently. It would seem that these small oddities make little difference but they eventually will accumulate to a point where the "gcc configure scripts" _overestimate_ the TARGET Linker's capabilities and mistake them for the HOST Linker's capabilities. If you build gcc, save a log of the build going in each direction, and then diff the two logs _MANY_ of the differences make sense but some make little sense at all: # ../gcc_trunk/configure ... --with-gnu-as --with-as=/usr/local/bin/as --without-gnu-ld --with-ld=/usr/ccs/bin/ld # gmake 2>&1 | tee made_16a_log.txt # ../gcc_trunk/configure ... --with-gnu-as --with-as=/opt/csw/bin/gas --without-gnu-ld --with-ld=/usr/ccs/bin/ld # gmake 2>&1 | tee made_17a_log.txt gdiff -Naur made_16a_log.txt made_17a_log.txt --- made_16a_log.txt 2009-02-03 15:05:11.445270964 -0800 +++ made_17a_log.txt 2009-02-05 08:16:22.532336517 -0800 ... -checking for catalogs to be installed... be da de el es fi fr ja nl ru sr sv tr zh_CN zh_TW +checking for catalogs to be installed... be da de el es fi fr id ja nl ru sr sv tr zh_CN zh_TW ... checking what objdump to use... /usr/local/i386-pc-solaris2.11/bin/objdump +checking for readelf... /usr/local/bin/readelf +checking what readelf to use... /usr/local/bin/readelf checking assembler for .balign and .p2align... yes ... checking assembler for .hidden... yes -checking linker for .hidden support... no +checking linker for .hidden support... yes +checking linker read-only and read-write section mixing... read-only checking assembler for .sleb128 and .uleb128... yes checking assembler for cfi directives... yes +checking assembler for working cfi advance... yes checking assembler for cfi personality directive... yes ... checking assembler for --debug-prefix-map option... yes +checking assembler for .lcomm with alignment... no checking assembler for tolerance to line number 0... yes -checking linker read-only and read-write section mixing... read-only checking linker PT_GNU_EH_FRAME support... no checking linker position independent executable support... no checking linker EH-compatible garbage collection of sections... /usr/local/i386-pc-solaris2.11/bin/objdump: 'conftest': No such file ... Lets see how that going to work out ... When you use an "installed gcc compiler" configured with: ../gcc_trunk/configure ... --with-gnu-as --with-as=/usr/local/bin/as --without-gnu-ld --with-ld=/usr/ccs/bin/ld to build gcc when it is ./configured with: # ../gcc_trunk/configure ... --with-gnu-as --with-as=/opt/csw/bin/gas --without-gnu-ld --with-ld=/usr/ccs/bin/ld will cause the build to break here: chmod a-wx rts/*.ali touch ../stamp-gnatlib-rts gmake[6]: Leaving directory `/usr/share/src/gcc_build/gcc/ada' rm -f rts/libgna*.so cd rts; ../../xgcc -v -B../../ -shared -g -O2 \ -fPIC \ -o libgnat-4.4.so \ a-assert.o a-calari.o a-caldel.o a-calend.o .......... -Wl,-h,libgnat-4.4.so \ -lposix4 -lnsl -lsocket -lm ... gcc version 4.4.0 20090204 (experimental) [trunk revision 143918] (GCC) COMPILER_PATH=../../:/usr/ccs/bin/ LIBRARY_PATH=../../:/lib/:/usr/lib/ COLLECT_GCC_OPTIONS='-v' '-B../../' '-shared' '-g' '-O2' '-fPIC' '-o' 'libgnat-4.4.so' '-mtune=k8' '-march=k8' ../../collect2 -V -G -dy -z text -Y P,/usr/ccs/lib:/usr/lib -Qy -o libgnat-4.4.so /usr/lib/crti.o .......... ld: Software Generation Utilities - Solaris Link Editors: 5.11-1.1624 Text relocation remains referenced against symbol offset in file .rodata (section) 0x42 a-assert.o (Thousands of Errors) _Unwind_Resume 0x3559 g-socket.o _Unwind_Resume 0x38f8 g-socket.o _Unwind_Resume 0x39d7 g-socket.o _Unwind_Resume 0x4161 g-socket.o _Unwind_Resume 0x46fc g-socket.o ld: fatal: relocations remain against allocatable but non-writable sections collect2: ld returned 1 exit status gmake[5]: *** [gnatlib-shared-default] Error 1 gmake[5]: Leaving directory `/usr/share/src/gcc_build/gcc/ada' gmake[4]: *** [gnatlib-shared-dual] Error 2 gmake[4]: Leaving directory `/usr/share/src/gcc_build/gcc/ada' gmake[3]: *** [gnatlib-shared] Error 2 gmake[3]: Leaving directory `/usr/share/src/gcc_build/gcc/ada' gmake[2]: *** [gnatlib-shared] Error 2 gmake[2]: Leaving directory `/usr/share/src/gcc_build/i386-pc-solaris2.11/libada' gmake[1]: *** [all-target-libada] Error 2 gmake[1]: Leaving directory `/usr/share/src/gcc_build' gmake: *** [all] Error 2 I edited "../gcc_build/gcc/ada/gcc-interface/Makefile" and tossed a "-v" into the command in MakefileTarget "gnatlib-shared-default" to double-check which Linker is being used. If I run the "collect2" command by hand and substitute Binutils' Linker then I get a good link with no errors. That makes me think this is going on: The scripts did "three-stage" the Compiler (gcc) so it could increase it's capabilities _and_ the scripts checked the gcc command line options to determine if the HOST and TARGET gcc had the same options. The scripts ARE ABLE to compensate for added or missing (depreciated) features in the Compiler. The scripts did NOT "three-stage" the Linker so it could increase (or, in this case, decrease) the available command line options and determine if the HOST and TARGET Linkers had the same options. The scripts are NOT ABLE to compensate for added or missing (depreciated) features in the Linker. Thanks, Rob
Correction (not careful enough with the cut-and-pasting): The "BUG" is this: If you compile gcc (using a gcc that uses Sun's Linker) to make a gcc Toolchain that uses GNU's Linker the resulting gcc Toolchain will WORK reasonably well and passes most "make -i check" tests. If you compile gcc (using a gcc that uses GNU's Linker) to make a gcc Toolchain that uses Sun's Linker the resulting gcc Toolchain will _NOT_ WORK since it can't be built without a few fixes to the scripts.
There really is some trouble with the scripts in this area. As you might expect simply restarting the make simply repeats the trouble, shows the same errors and ends the build. If you restart the build with "gmake -i -k" then you will get _many_ errors for those three shared libraries _BUT_ the build will continue. The Makefile will 'discover' that those libs are missing and it rebuilds those errant object files -- it ends up re-making those libraries and building correctly a second time around after using "gmake -i -k". A subsequent use of simply "gmake" (no "-i -k") will not build _any_ new files. Now simply use "gmake install" to complete everything. I am very early in the "make -i check" tests but they seem to be working OK and gcc seems to pass the same tests for "C" or "Ada" with Sun's Linker as opposed to the prior run with GNU's Linker. Rob
Despite all the problems Ada passes _all_ of it's Testsuite: http://gcc.gnu.org/ml/gcc-testresults/2009-02/msg00620.html
(In reply to comment #3) > Despite all the problems Ada passes _all_ of it's Testsuite: > http://gcc.gnu.org/ml/gcc-testresults/2009-02/msg00620.html > My Testsuite Submission bounced, please view these results instead: http://gcc.gnu.org/ml/gcc-testresults/2009-02/msg00707.html
(In reply to comment #0) > On Solaris (and HPUX, other ...) Operating Systems the OS's Manufacturer > has their own Linker and recommends it be used for all linking. > ... > Note that in both of the commonly available compilers for Solaris the > person who built gcc used Sun's linker. It is dated "Nov 19 2008". > > # /usr/ccs/bin/ld -V > ld: Software Generation Utilities - Solaris Link Editors: 5.11-1.1624 *** FLAG DAY *** OpenSolaris users must upgrade Sun's Linker if they wish to use it. Currently, OpenSolaris 2009.06 works correctly and outputs this on query: # /usr/ccs/bin/ld -V ld: Software Generation Utilities - Solaris Link Editors: 5.11-1.1639 Thanks, Rob
The "reverse" is broken in "trunk revision 144266" on OpenSolaris 2009.06. Previously the 'reverse of this Bug' worked, regression. With "trunk revision 144266" installed and ./configured with: "--without-gnu-ld --with-ld=/usr/bin/ld" (Sun linker) trying to build "trunk revision 144279" ./configured with: "--with-gnu-ld --with-ld=/usr/local/bin/ld" (GNU Linker) fails to build; but used to work with revisions from last month. Installed Compiler: # gcc -v Using built-in specs. Target: i386-pc-solaris2.11 Configured with: ../gcc_trunk/configure --build=i386-pc-solaris2.11 --enable-languages=ada,c,c++,fortran,java,objc,obj-c++ --enable-shared --disable-static --enable-multilib --enable-decimal-float --with-long-double-128 --with-included-gettext --enable-stage1-checking --enable-checking=release --with-tune=k8 --with-cpu=k8 --with-arch=k8 --with-gnu-as --with-as=/usr/local/bin/as --without-gnu-ld --with-ld=/usr/bin/ld --with-gmp=/usr/local --with-mpfr=/usr/local --without-ppl Thread model: posix gcc version 4.4.0 20090218 (experimental) [trunk revision 144266] (GCC) Building this: # gcc/xgcc -v Using built-in specs. Target: i386-pc-solaris2.11 Configured with: ../gcc_trunk/configure --prefix=/usr/local/gcc4 --enable-languages=ada,c,c++,fortran,java,objc,obj-c++ --enable-shared --disable-static --enable-multilib --enable-decimal-float --with-long-double-128 --with-included-gettext --enable-stage1-checking --enable-checking=release --with-tune=k8 --with-cpu=k8 --with-arch=k8 --with-gnu-as --with-as=/usr/local/bin/as --with-gnu-ld --with-ld=/usr/local/bin/ld --with-gmp=/usr/local --with-mpfr=/usr/local --without-ppl Thread model: posix gcc version 4.4.0 20090218 (experimental) [trunk revision 144279] (GCC) FAILS during the confused build. The Sun Linker is kept (wrong) and the script / Makefiles send GNU Linker compatible commands (correct) to the Sun Linker (oops). The 'workaround' is to ./configure with a different "--prefix=" and use "--enable-languages=ada,c" (as a minimum). Get at least the "C" and "Ada" Languages build. Install the Compiler. Alter your PATH to the _NEW_ Compiler (that uses GNU ld). Redo the ./configure and then re-build gcc. This time there can be no cross-linker-Bootstrap confusion. Rob
As I've said before: please file *clear individual bug reports* for each single issue you find. Dealing with reports like this, with dozens of issues and non- issues mixed, is close to impossible.
>> As I've said before: please file *clear individual bug reports* for each single >> issue you find. Dealing with reports like this, with dozens of issues and non- >> issues mixed, is close to impossible. I'll stick with comment #1 describes the Bug. Further comments were workarounds and to report a "Flag Day" on the Sun Linker. Rob
Subject: Re: gcc 4.4.0 20090204 - Configury from GNU linker to Operating System's Linker broke (reverse works OK) > ------- Comment #8 from rob1weld at aol dot com 2010-05-04 07:05 ------- >>> As I've said before: please file *clear individual bug reports* for each single >>> issue you find. Dealing with reports like this, with dozens of issues and non- >>> issues mixed, is close to impossible. > > I'll stick with comment #1 describes the Bug. The beef of your report seems to be: I get errors from Sun ld linking libgnat-4.4.so. In my experience, this only happens when you re-run make bootstrap in a completed build or re-start it after the build failed at some point. For some reason, the libgnat objects seem to be rebuild without -fPIC, leading to the observed error. Seems like a bug in the Ada build system to me. > Further comments were workarounds and to report a "Flag Day" on the Sun Linker. I don't think there is any flag day involved, this error just depends very much on the circumstances of the build. I simply used to remove the gcc/ada/rts{, rts_amd64} directories and a couple of stamp files when I encountered this, though I haven't in a long time. Perhaps the build system error is gone now. Rainer
No response in a year.