Subject: Nobody in the world understands Gnu's 'ld'.
From: [email-masked] ("D. Jeff Dionne")

25 Mar 1997 20:41:29 -0800
Approved: [email-masked]
Distribution: cygnus
Message-ID: <[email-masked]>
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Original-To: [email-masked]
X-Mailer: ELM [version 2.4 PL25]
Original-Sender: [email-masked]

[stuff chopped]
> Since several months people here report that Cygnus's linker is flawed.
> I think that it is just plain that Cygnus doesn't have the
> know-how to repair it, since Steve Chamberlain, the guy that
> wrote most of it, hasn't posted anything here since ages and
> he was very active before.
> 

If this is indeed the case, this is IMHO unfortunate.  I wonder if
the departure has anything to do with the license nonsense Cygnus is
engaged in of late...  But on to 'ld' specific stuff...

[chop]
> 
> Just to give you an idea, ld is supposed to link an object file
> from sun's unix format with some code from windows 95 and with
> some code of hp Unix. Of course this is ridiculous and it will never
> work, but this is how 'ld' is designed: 

Oh rubbish.  The fact that 'ld' (or more correctly, BFD) supports _many_
file formats is absolutely _useful_.  On 68k I've used just about 
everything BFD has to offer, and would still be messing around with
little bits of custom code if it did'nt!

> an incredible complexity
> that (to me) seems completely unwarranted. It has a full blown LANGUAGE
> (with lex+yacc parser/lexer!) that is supposed to recognize linker
> commands. Obviously nobody ever uses it, but to understand
> what the linker is doing you have to go through yet another layer
> of complexity.

I must admit if I could find some docs on it, I'd be happy.  I could
always go read the yacc code, but I get on with it reasonably well so
far without.  This again is a _great_ thing, very useful.  Ppl (like
me) _do_ use it.

> 
> Then you have the 'BFD' format, that is supposed to be an universal
> binary format designed by GNU that will abstract the binary format
> of all machines in the western world into ONE format. Obviously
> it doesn't work, 

Not format.  Set of 'back ends' to any and all file formats with a consistant 
interface.  Works quite well, very useful.

> but then you have not only to understand what
> binary format you have in windows (what is difficult enough) but
> you have to understand BFD too.

Nonsense.  If you only need to understand the interface that BFD provides,
and in most cases not even the file format you're working with.  If you
just had a bunch of random functions that mess about with your file
format, you'd need to understand those and you've gained absolutly nothing.
Next file format, next set of nonsense.  BFD solves that.  It's not 
fundamentally BFD's fault if the Win32 implementation it has is broken...

[chop]
> 
> And to crown this beatiful construction there is NO DOCUMENTATION
> whatsoever about anything I have told you in this message. I inferred
> this from reading THE C CODE!!!

Actually, IMHO the construction _is_ nice, but the lack of accessable 
documentation is a hinderance to ppl using this stuff.  I wrote some
tools to convert any BFD supported object format into 'resources' for
the USR Pilot PDA device and had to rely on code from something else,
and a look at the headers to figure out what functions in libbfd.a to
call :-(  I would prefer to just build this stuff into BFD, but...
If the documentation does exist, it would be a great help if it could
be made more accessable (perhaps stick a pointer to it somewhere we
can find it easily)?

[chop]
> I think that anybody using 'ld' is living very dangerously...

'ld' is not perfect, and BFD seems to have a few inconsistant things in
the way it handles even (nornal) COFF files, and the situation is
frustrated by not being able to locate documenetation.  That having
been said, 'ld' (and BFD and the rest of binutils) are things I can't
live without when doing something more than just... ho hum... build
me an executable for a standard supported target.  When doing a new target
(like for instance the USR Pilot, or an embedded system), the flexibility
'ld' gives with it's little 'linker' language means I can build an 'ld'
_OUT OF THE BOX_ and produce _TARGET SPECIFIC_ output without modification
to it's code.  This is a plus.  I don't need to mess about with funny
conversion programs (they are taking about this over on the mc68332
list today) to make any kind of file format I want, or 5 of them, thanks
to BFD.  We need to get those docs accessable, though.

Jeff.

> 
> -- 
> Jacob Navia	Logiciels/Informatique
> 41 rue Maurice Ravel			Tel 01 48.23.51.44
> 93430 Villetaneuse 			Fax 01 48.23.95.39
> France
> -
> For help on using this list, send a message to
> "[email-masked]" with one line of text: "help".
> 

-
For help on using this list, send a message to
"[email-masked]" with one line of text: "help".