[Bug bootstrap/39111] New: gcc 4.4.0 20090204 - Configury from GNU linker to Operating System's Linker broke (reverse works OK)

[Bug bootstrap/39111] New: gcc 4.4.0 20090204 - Configury from GNU linker to Operating System's Linker broke (reverse works OK)

[rob1weld at aol dot com]

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


-- 
           Summary: gcc 4.4.0 20090204 - Configury from GNU linker to
                    Operating System's Linker broke (reverse works OK)
           Product: gcc
           Version: 4.4.0
            Status: UNCONFIRMED
          Severity: major
          Priority: P3
         Component: bootstrap
        AssignedTo: unassigned at gcc dot gnu dot org
        ReportedBy: rob1weld at aol dot com
 GCC build triplet: i386-pc-solaris2.11
  GCC host triplet: i386-pc-solaris2.11
GCC target triplet: i386-pc-solaris2.11


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39111

[Bug bootstrap/39111] gcc 4.4.0 20090204 - Configury from GNU linker to Operating System's Linker broke (reverse works OK)

[rob1weld at aol dot com]

------- Comment #1 from rob1weld at aol dot com  2009-02-05 18:36 -------
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.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39111

[Bug bootstrap/39111] gcc 4.4.0 20090204 - Configury from GNU linker to Operating System's Linker broke (reverse works OK)

[rob1weld at aol dot com]

------- Comment #2 from rob1weld at aol dot com  2009-02-06 02:15 -------
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


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39111

[Bug bootstrap/39111] gcc 4.4.0 20090204 - Configury from GNU linker to Operating System's Linker broke (reverse works OK)

[rob1weld at aol dot com]

------- Comment #3 from rob1weld at aol dot com  2009-02-06 13:19 -------
Despite all the problems Ada passes _all_ of it's Testsuite:
http://gcc.gnu.org/ml/gcc-testresults/2009-02/msg00620.html


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39111

[Bug bootstrap/39111] gcc 4.4.0 20090204 - Configury from GNU linker to Operating System's Linker broke (reverse works OK)

[rob1weld at aol dot com]

------- Comment #4 from rob1weld at aol dot com  2009-02-07 11:04 -------
(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


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39111

[Bug bootstrap/39111] gcc 4.4.0 20090204 - Configury from GNU linker to Operating System's Linker broke (reverse works OK)

[rob1weld at aol dot com]

------- Comment #5 from rob1weld at aol dot com  2009-02-12 14:04 -------
(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


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39111

[Bug bootstrap/39111] gcc 4.4.0 20090204 - Configury from GNU linker to Operating System's Linker broke (reverse works OK)

[rob1weld at aol dot com]

------- Comment #6 from rob1weld at aol dot com  2009-02-19 06:17 -------
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


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39111

[Bug bootstrap/39111] gcc 4.4.0 20090204 - Configury from GNU linker to Operating System's Linker broke (reverse works OK)

[ro at gcc dot gnu dot org]

------- Comment #7 from ro at gcc dot gnu dot org  2010-04-28 20:00 -------
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.


-- 

ro at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |ro at gcc dot gnu dot org
             Status|UNCONFIRMED                 |WAITING


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39111

[Bug bootstrap/39111] gcc 4.4.0 20090204 - Configury from GNU linker to Operating System's Linker broke (reverse works OK)

[rob1weld at aol dot com]

------- 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.

Further comments were workarounds and to report a "Flag Day" on the Sun Linker.

Rob


-- 

rob1weld at aol dot com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|WAITING                     |UNCONFIRMED


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39111

[Bug bootstrap/39111] gcc 4.4.0 20090204 - Configury from GNU linker to Operating System's Linker broke (reverse works OK)

[ro at CeBiTec dot Uni-Bielefeld dot DE]

------- Comment #9 from ro at CeBiTec dot Uni-Bielefeld dot DE  2010-05-06 19:32 -------
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


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39111

[Bug bootstrap/39111] gcc 4.4.0 20090204 - Configury from GNU linker to Operating System's Linker broke (reverse works OK)

[ro at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39111

Rainer Orth <ro at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |RESOLVED
         Resolution|                            |INVALID

--- Comment #10 from Rainer Orth <ro at gcc dot gnu.org> 2011-07-18 16:52:44 UTC ---
No response in a year.