From: fjh AT cs DOT mu DOT OZ DOT AU (Fergus Henderson) Subject: Re: Mr Taylor surely understands ld: a correction to my previous post 27 Mar 1997 12:11:07 -0800 Approved: cygnus DOT gnu-win32 AT cygnus DOT com Distribution: cygnus Message-ID: <199703270221.NAA05628.cygnus.gnu-win32@mundook.cs.mu.OZ.AU> Content-Type: text Original-To: root AT jacob DOT remcomp DOT fr (root) Original-Cc: gnu-win32 AT cygnus DOT com (gnu-win32) In-Reply-To: from "root" at Mar 25, 97 07:09:02 pm X-Mailer: ELM [version 2.4 PL24] Original-Sender: owner-gnu-win32 AT cygnus DOT com Jacob Navia wrote: > > But it is the whole philosophy behind this that is flawed. > Mr Taylor writes: > > > ...the linker is able to generate an object file > > format which is different from the input file formats. For example, > > this permits the linker to directly generate S-record output without > > requiring a convertor. > > But WHY do we have to put the convertor and the linker in the SAME PROGRAM!!! Here's one possible reason (there may be others). Different object file formats formats have different sets of capabilities. In general, conversion from one format to another format may not be able to preserve all the information. If the linker required all inputs to have the same format, then you might have to use a lossy conversion, and that might prevent successful linking. One possible solution to this problem would be to invent a new object file format whose capabilities were a superset of the capabilities of all other object file formats. Then, you could ensure that the conversion to this object file format was non-lossy. However, this approach would be more complex than the BFD approach, not less complex. -- Fergus Henderson | "I have always known that the pursuit WWW: | of excellence is a lethal habit" PGP: finger fjh AT 128 DOT 250 DOT 37 DOT 3 | -- the last words of T. S. Garp. - For help on using this list, send a message to "gnu-win32-request AT cygnus DOT com" with one line of text: "help".