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