From: jeff AT ls1 DOT pfnet DOT com ("D. Jeff Dionne") Subject: Nobody in the world understands Gnu's 'ld'. 25 Mar 1997 20:41:29 -0800 Approved: cygnus DOT gnu-win32 AT cygnus DOT com Distribution: cygnus Message-ID: <199703252118.QAA01690.cygnus.gnu-win32@ls1.pfnet.com> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Original-To: gnu-win32 AT cygnus DOT com X-Mailer: ELM [version 2.4 PL25] Original-Sender: owner-gnu-win32 AT cygnus DOT com [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 > "gnu-win32-request AT cygnus DOT com" with one line of text: "help". > - For help on using this list, send a message to "gnu-win32-request AT cygnus DOT com" with one line of text: "help".