GNU ld vs. Sun ld
Pasha Zusmanovich
Here is the situation:
We have a large application on SunOS 4.1.4 currently compiling with gcc
and Sun ld. Because it contains a load of inter-dependent libraries,
sometimes it is a non-trivial task to figure out a right order in which
they should supplied to ld (sometimes more than one time) to compile
different parts of application. As GNU ld has a "multiple pass" option
(i.e. pass through supplied libraries until all references will be
resolved) I strongly think to switch to GNU ld. Some preliminary tests
don't show any problems, except that resulting execs (linked with Sun
and GNU ld) are different: unstripped GNU versions are 1.5-2-3 times
smaller than a SUN one, and stripped GNU versions sometimes are little
bigger. This puzzles me. I didn't expect that execs would be identical,
but different in size?
It seems that somewhere I saw some warnings about using of GNU ld on Sun
systems (or it is just my imagination?)
Any exeprience/opinions on using GNU ld vs. Sun ld would be greatly
welcomed.
--
Pasha Zusmanovich -------o x x "What i tell you three times is true."
pa...@isracom.net.il o o x L.Carroll, "The Hunting of the Snark"
www.isracom.net.il/~pasha x x o---------------------------------------
Nico Garcia
Pasha Zusmanovich <pa...@isracom.net.il> writes:
> We have a large application on SunOS 4.1.4 currently compiling with gcc
> and Sun ld. Because it contains a load of inter-dependent libraries,
> sometimes it is a non-trivial task to figure out a right order in which
> they should supplied to ld (sometimes more than one time) to compile
> different parts of application. As GNU ld has a "multiple pass" option
> (i.e. pass through supplied libraries until all references will be
> resolved) I strongly think to switch to GNU ld. Some preliminary tests
> don't show any problems, except that resulting execs (linked with Sun
> and GNU ld) are different: unstripped GNU versions are 1.5-2-3 times
> smaller than a SUN one, and stripped GNU versions sometimes are little
> bigger. This puzzles me. I didn't expect that execs would be identical,
> but different in size?
Don't do this. Many GNU users have had exceptional difficulty, with this.
What is wrong with using just gcc/libg++? It is completely reasonable
to specify, by hand, "-L/libdir -llibrary" style options to get the right
thing for specific libraries.
--
Nico Garcia
ra...@tiac.net
<PGP is obviously a good idea: look at who objects to it.>
Pasha Zusmanovich
I am grateful to all people replied to my initial question.
There is basically two type of answers:
1. GNU ld is better, and there are no problems with it
2. GNU ld on Sun platforms is buggy and problematic, use vendor ld
instead.
Ok, my (very limited) experince tends to be closer to 1. Anyway, the
range of options provided by GNU ld beats Sun ld to the punch. Also, you
need it if you want to use cross-compilation features of gcc. So I
extremely would like to hear more thorough evidence and explanation of
2.
Next, if 2 is true (at least to some extent), it is something specific
to Sun platforms? (I cannot believe that people produce such complicated
and sucessfull programs as Linux kernel using "bad" ld). If yes, why?
Hope I am not raising here a "holy war" issue.
Thank you all guys again.
Casper H.S. Dik - Network Security Engineer
[[ PLEASE DON'T SEND ME EMAIL COPIES OF POSTINGS ]]
Pasha Zusmanovich <pa...@isracom.net.il> writes:
>I am grateful to all people replied to my initial question.
>There is basically two type of answers:
>1. GNU ld is better, and there are no problems with it
>2. GNU ld on Sun platforms is buggy and problematic, use vendor ld
>instead.
On Solaris, question #2 is the right answer :-)
>Ok, my (very limited) experince tends to be closer to 1. Anyway, the
>range of options provided by GNU ld beats Sun ld to the punch. Also, you
>need it if you want to use cross-compilation features of gcc. So I
>extremely would like to hear more thorough evidence and explanation of
>2.
You need it but only for tyhose environments you cross-compile to.
(Each X environment gets it's own linker)
>Next, if 2 is true (at least to some extent), it is something specific
>to Sun platforms? (I cannot believe that people produce such complicated
>and sucessfull programs as Linux kernel using "bad" ld). If yes, why?
The Solaris linker is a target that moves at a pace. The GNU linker has
never been able to keep up with it. I don't thinkj, e.g., that it now
supports versioning/scoping as the Solaris linker does.
(I.e., GNU ld linked objects will not record scoping information)
There has also been a long history of problems associated with
GNU ld; it 's support for dynamic linking was late and then it was
broken for a long while.
Many people also installed gas as it's in the same package, but gas didn't
support PIC code for quite some time.
In the years that I've answered questions on build problems on Solaris 2.x,
"rm -f gas gld; use Solaris ld/as" ranked as answer second only to
"reinstall gcc, you need newly fixed include files".
The Sun linker/assembler work fine; they do support the latest OS features
and work as, e.g., perl dynamic linking expects. The resultant executables
are supported (if the linker messes things up afterall)
Helping out some of the customer tech support people here, I've also found
that older versions of GNU ld made a real mess of executables. GNU ld
alone being responsible for all executables having a symbol table that was
not only about 40K bigger but also pulled in *all* weak data references,
inclkuding private ones, from the library. This was 40K on a 44K executable,
i.e., when they switch linker it was a 4K executable.
This wasn't a problem until they switched to Solaris 2.6 which no longer
exports private libc symbols; all their products wouldn't work under 2.6
and only because of GNU ld, though admittedly an old version.
Casper
--
Expressed in this posting are my opinions. They are in no way related
to opinions held by my employer, Sun Microsystems.
Statements on Sun products included here are not gospel and may
be fiction rather than truth.
Paul Eggert
Caspe...@Holland.Sun.Com (Casper H.S. Dik - Network Security Engineer) writes:
>Pasha Zusmanovich <pa...@isracom.net.il> writes:
>>1. GNU ld is better, and there are no problems with it
>>2. GNU ld on Sun platforms is buggy and problematic, use vendor ld
>>instead.
>On Solaris, question #2 is the right answer :-)
Historically that was true, but currently I would say that it depends
on what you want to do. In particular, if you want to use Dwarf-2
debugging format, you can't use Solaris ld because it botches symbolic
relocations to unaligned data. That's too bad, since Dwarf-2 format is
often preferred.
I attempted to file this as a bug report back in February but never
succeeded in connecting with someone at Sun who could see that the bug
got fixed; eventually I gave up.
Here's an example of the Solaris ld bug, using Solaris 2.6 with the
Sun patch 105490-02 (the latest public linker patch installed):
$ uname -a
SunOS shade.twinsun.com 5.6 Generic_105181-04 sun4u sparc SUNW,Ultra-1
$ ld -V
ld: Software Generation Utilities - Solaris/ELF (3.0)
$ ls -l /usr/ccs/bin/ld
-rwxr-xr-x 1 bin bin 8468 Apr 16 15:46 /usr/ccs/bin/ld
$ gcc -v
Reading specs from /opt/reb/lib/gcc-lib/sparc-sun-solaris2.6/2.8.1/specs
gcc version 2.8.1
$ cat t.c
int main() { return 0; }
$ gcc -gdwarf-2 t.c
ld: warning: relocation error: R_SPARC_32: file /tmp/cc0FuL.K1.o: symbol .text:
external symbolic relocation against non-allocatable section .debug_line;
cannot be processed at runtime: relocation ignored
ld: warning: relocation error: R_SPARC_UA32: file /tmp/cc0FuL.K1.o: symbol .debug_abbrev:
external symbolic relocation against non-allocatable section .debug_info;
cannot be processed at runtime: relocation ignored
ld: warning: relocation error: R_SPARC_UA32: file /tmp/cc0FuL.K1.o: symbol .text:
external symbolic relocation against non-allocatable section .debug_info;
cannot be processed at runtime: relocation ignored
ld: warning: relocation error: R_SPARC_UA32: file /tmp/cc0FuL.K1.o: symbol .debug_line:
external symbolic relocation against non-allocatable section .debug_info;
cannot be processed at runtime: relocation ignored
ld: warning: relocation error: R_SPARC_UA32: file /tmp/cc0FuL.K1.o: symbol .debug_info:
external symbolic relocation against non-allocatable section .debug_pubnames;
cannot be processed at runtime: relocation ignored
ld: warning: relocation error: R_SPARC_UA32: file /tmp/cc0FuL.K1.o: symbol .debug_info:
external symbolic relocation against non-allocatable section .debug_aranges;
cannot be processed at runtime: relocation ignored
ld: warning: relocation error: R_SPARC_32: file /tmp/cc0FuL.K1.o: symbol .text:
external symbolic relocation against non-allocatable section .debug_aranges;
cannot be processed at runtime: relocation ignored
Undefined first referenced
symbol in file
.debug_info /tmp/cc0FuL.K1.o
.text /tmp/cc0FuL.K1.o
.debug_abbrev /tmp/cc0FuL.K1.o
.debug_line /tmp/cc0FuL.K1.o
ld: fatal: Symbol referencing errors. No output written to a.out
Volker Borchert
In article <354B13C5...@isracom.net.il>, Pasha Zusmanovich <pa...@isracom.net.il> writes:
|> I am grateful to all people replied to my initial question.
|>
|> There is basically two type of answers:
|>
|> 2. GNU ld on Sun platforms is buggy and problematic, use vendor ld
|> instead.
You cannot link a SunOS 4 kernel using GNU ld. At least not without
messing with the makefile, which in turn is automatically generated...
vb
--
"I'm a doctor, not a mechanic." Dr Leonard McCoy <mc...@ncc1701.starfleet.fed>
"I'm a mechanic, not a doctor." Volker Borchert <b...@teknon.de>