User account creation filtered due to spam.

Bug 39111 - gcc 4.4.0 20090204 - Configury from GNU linker to Operating System's Linker broke (reverse works OK)
Summary: gcc 4.4.0 20090204 - Configury from GNU linker to Operating System's Linker b...
Status: RESOLVED INVALID
Alias: None
Product: gcc
Classification: Unclassified
Component: bootstrap (show other bugs)
Version: 4.4.0
: P3 major
Target Milestone: ---
Assignee: Not yet assigned to anyone
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2009-02-05 18:32 UTC by Rob
Modified: 2011-07-18 16:52 UTC (History)
2 users (show)

See Also:
Host: i386-pc-solaris2.11
Target: i386-pc-solaris2.11
Build: i386-pc-solaris2.11
Known to work:
Known to fail:
Last reconfirmed:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Rob 2009-02-05 18:32:50 UTC
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
Comment 1 Rob 2009-02-05 18:36:47 UTC
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.

Comment 2 Rob 2009-02-06 02:15:39 UTC
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
Comment 3 Rob 2009-02-06 13:19:11 UTC
Despite all the problems Ada passes _all_ of it's Testsuite:
http://gcc.gnu.org/ml/gcc-testresults/2009-02/msg00620.html
Comment 4 Rob 2009-02-07 11:04:30 UTC
(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
Comment 5 Rob 2009-02-12 14:04:26 UTC
(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
Comment 6 Rob 2009-02-19 06:17:44 UTC
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
Comment 7 Rainer Orth 2010-04-28 20:00:32 UTC
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.
Comment 8 Rob 2010-05-04 07:05:47 UTC
>> 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
Comment 9 ro@CeBiTec.Uni-Bielefeld.DE 2010-05-06 19:32:25 UTC
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
Comment 10 Rainer Orth 2011-07-18 16:52:44 UTC
No response in a year.