Re: Nobody in the world understands Gnu's 'ld'.

Re: Nobody in the world understands Gnu's 'ld'.

[Ian Lance Taylor]

In gnu-win32 root@jacob.remcomp.fr writes:

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

Let's not get carried away here.  I understand the linker perfectly
well, and so do a number of other people.

It's true that Steve Chamberlain left Cygnus a while ago.

If you look at the ChangeLog files, you can see who has been working
on the linker and other parts of BFD.  You'll see that although Steve
wrote most of the original code several years ago, he hasn't been
heavily involved with BFD or the linker for quite some time.

>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: an incredible complexity
>that (to me) seems completely unwarranted.

It's true that it is rare for people to link together different object
file formats.  However, you have missed the actual reasons for the
complexity.

The first reason is that 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.  This may not be too useful for native
programmers, but it is useful for embedded systems programmers.

The second reason is that a single linker binary can serve as the
linker for different targets.  The Linux people use this, for example:
the binary binutils distribution for Linux is built to support all the
various Linux targets in a single binary.

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

In fact, many people use the linker script language.  I can't imagine
why you think that nobody uses it.  Moreover, this is hardly a unique
or even unusual feature of the GNU linker: most linkers have a
scripting language, and the one used by the GNU linker is based on the
one used by the SVR3 linker.

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

In fact, BFD works quite well.  I don't know why you think that it
doesn't work.

It's not quite correct to describe BFD as abtracting all binary
formats into one format.  What it actually does is provide a library
interface which may be used to examine and generate an object file in
any format.

Mind you, I'm not going to defend the way that BFD is written.  There
is definitely a very steep learning curve before being able to program
using BFD.  I've tried to clean up some of the more egregious
problems.  Unfortunately, the cost of rewriting BFD is high.

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

I'd love to have some documentation if you care to write some and
contribute it.  This is, after all, free software.  It improves by
contributions.

>That is why this linker can't even recognize MSVC object code
>format and use the MSVC .LIBs. Because nobody in the world
>is able to modify it. Of course we do not need compatibility
>with SUN or HP Unix under Windows 95. We would need MSVC
>compatibility. But to do that we would have to find somebody
>that understands 'ld'...

Well, all you need to do is add support for the object code format to
BFD.  I'm sorry you think that is impossible.  In fact, BFD supports a
number of object file formats already, including a.out, COFF, ELF,
IEEE-695, XCOFF, SOM, etc.  Adding another one is really not all that
difficult if you know what you are doing.

I'm always willing to answer specific questions about BFD and the
linker.  I'm not willing to give a tutorial on how to program it,
because I simply don't have the time.

I suppose I should add that my personal interest in adding MSVC object
support is nil.  I do work at Cygnus, but I don't work on gnu-win32,
and I have no idea whether Cygnus has any plans to do anything in this
area.

Ian
-
For help on using this list, send a message to
"gnu-win32-request@cygnus.com" with one line of text: "help".

Mr Taylor surely understands ld: a correction to my previous post

[root]

I sent earlier this morning a message stating that nobody understands ld.

This is surely not true for Mr Taylor.

I saw his comments when reading ld's code, and they were helpful.
I just let myself go, expressing (for the first time I think) this feeling of
frustration I got from my weeks studying that code.

There are some basic rules of software engineering that we somehow take for
granted. For instance, a .h file contains declarations, and a .c file contains
executable code. This is not the case with 'ld'. The file 'coff.h' contains
executable code that is included TWICE (yes, the same file) in the code of
'ld' with different #defines as input. This works because all the functions
in that file are declared static and accessed by several indirection tables. 

Problem is, most debuggers get confused with this... not to speak of the poor 
guy *reading* that code!

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!!!
In my view of things, it would be much better to have an easy to understand
convertor to be used by systems programmers when they need S records, than
to overload the linker with YET ANOTHER LEVEL OF COMPLEXITY!!!

Besides, 99.9999% of the people that use 'ld' daily, are loading that code 
to produce S records FOR NOTHING. The linker takes more space and is more
difficult to maintain! 

MODULARITY is a thing that got lost in this 'ld' crazyness. Do a program to
do ONE THING and do that well. Do another program for another task. Do not
build program upon program in the same executable. You do not have a
razor inside your TV set in case you want to shave yourself when watching
TV!!!

The linker I wrote, went the opposite direction: It is FAST, and its size is
only 66K. It understands only ONE format: windows COFF object. It will crash
with any other object file. It doesn't produce S-records, but it does produce
a readable MAP FILE with the information of the offset of EACH LINE in your
object code. And it uses Microsoft's debug info format, so you can even
debug it... :-)

What are the consequences of building things like 'ld'?

They are better expressed by this (anonymous) comment
in the file 'reloc.c'

/* This relocation routine is used by some of the backend linkers.
   They do not construct asymbol or arelent structures, so there is no
   reason for them to use bfd_perform_relocation.  Also,               <<<<<
   bfd_perform_relocation is so hacked up it is easier to write a new  <<<<<
   function than to try to deal with it.                               <<<<<
*/

So, instead of dealing with 'bfd_perform_relocation', that should relocate
object code from one object format into another (!!), people write their own
routines again, since that function is beyond what a human mind can follow!


The fact remains, that ld is producing bad executables since a long time.
Sometimes. When the program gets big enough, or when somehow a new API call
is invoked. There were people that pointed that out 2-3 months ago. A program
stopped working when it reached a size threshold. I have seen no announcements
of any corrections.

I still remain convinced that only Steve can fix this. It is a pity that he
is gone. This means that this problem will remain as it is in the foreseeable
future.

-- 
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@cygnus.com" with one line of text: "help".

Re: Mr Taylor surely understands ld: a correction to my previous post

[Fergus Henderson]

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 <fjh@cs.mu.oz.au>   |  "I have always known that the pursuit
WWW: < http://www.cs.mu.oz.au/~fjh >   |  of excellence is a lethal habit"
PGP: finger fjh@128.250.37.3         |     -- the last words of T. S. Garp.
-
For help on using this list, send a message to
"gnu-win32-request@cygnus.com" with one line of text: "help".

Re: Nobody in the world understands Gnu's 'ld'.

[Fergus Henderson]

Ian Lance Taylor wrote:
> 
> Let's not get carried away here.  I understand the linker perfectly
> well, and so do a number of other people.
[...]
> In fact, BFD works quite well.

Yes, I agree.  Let's not get carried away.

However, let's not forget the point either: the GNU ld code
is poorly structured and poorly documented.

> Mind you, I'm not going to defend the way that BFD is written.
> [...] I've tried to clean up some of the more egregious
> problems.  Unfortunately, the cost of rewriting BFD is high.

Right.  So what is the solution?  Well, in the case of BFD, perhaps the
damage is already done -- the cost would have been a lot cheaper if it
was done right in the first place.  However, even now, Cygnus should
seriously consider spending the money to improve the quality of their
existing source code, because it may be a *good investment*.

Regardless of what happens with BFD, Cygnus ought to ensure that
whatever code they write is well documented and properly structured.
This will result in products that are easier to maintain, easier
to extend, and as a result in the long term the products will be better.

> I'd love to have some documentation if you care to write some and
> contribute it.  This is, after all, free software.  It improves by
> contributions.

Documentation should not be an after-thought.  If Cygnus thinks that
it can economize by not bothering with documentation or not bothering
to write properly structured code, then they are wrong -- it may result
in some short-term gains, but in the long run it will cost them a lot.
It is much more difficult (and expensive) for someone to come along
afterwards and write documentation than for the person doing the
original work to write the documentation properly in the first place.

-- 
Fergus Henderson <fjh@cs.mu.oz.au>   |  "I have always known that the pursuit
WWW: < http://www.cs.mu.oz.au/~fjh >   |  of excellence is a lethal habit"
PGP: finger fjh@128.250.37.3         |     -- the last words of T. S. Garp.
-
For help on using this list, send a message to
"gnu-win32-request@cygnus.com" with one line of text: "help".

Re: Nobody in the world understands Gnu's 'ld'.

[Joel Dinolt]

Fergus Henderson wrote:

> Regardless of what happens with BFD, Cygnus ought to ensure that
> whatever code they write is well documented and properly structured.
> This will result in products that are easier to maintain, easier
> to extend, and as a result in the long term the products will be better.
<cut> 
I don't know if all this stuff about "Cygnus should do this, Cygnus
should do that..." is accurate...I thought GNU ld was part of the
standart GNU package, and that the ld with cyg-win32 was just a port
win32 port of the standard GNU ld. If this is the case, it's not
really Cygnus that should be "making sure it is well documented
and properly structured."  I would assume that the structure has been
an evolution over many years(like emacs or rcs or cvs) and has been
tinkered with by many people.  And as far as documentation, it might
be easiest to start at the GNU Home Page, since it is the cyg-win32 
ld is based on the standard GNU ld...of course, if the ld is 
a custom linker that cygnus wrote, it's another matter...but
free software is free software, and you have the source, as
cryptic as it may be.  Isn't 70% of programming getting frustrated
by having to read someone elses oddly structured code to figure out
what it does?  I could be speaking from a somewhat tainted perspective
here, as I'm a video game programmer doing a port, and I do windows
programming "for fun"....

Regards,
Joel Dinolt,
jdinolt@pacbell.net
-
For help on using this list, send a message to
"gnu-win32-request@cygnus.com" with one line of text: "help".

Re: Nobody in the world understands Gnu's 'ld'.

[Fergus Henderson]

Joel Dinolt wrote:
> 
> I thought GNU ld was part of the
> standart GNU package, and that the ld with cyg-win32 was just a port
> win32 port of the standard GNU ld. If this is the case, it's not
> really Cygnus that should be "making sure it is well documented
> and properly structured."

`ld' is part of the GNU binutils package, but Cygnus is (I believe)
the central maintainer of that package, just as Linus is the central
maintainer of the Linux kernel, Richard Kenner of the FSF is the
central maintainer of gcc, etc.

> I would assume that the structure has been
> an evolution over many years(like emacs or rcs or cvs) and has been
> tinkered with by many people.

Of course, but central maintainer who is responsible for merging in
all the different patches, issuing new releases, etc., should also
be responsible for maintaining the quality of the software.

> And as far as documentation, it might
> be easiest to start at the GNU Home Page, since it is the cyg-win32 
> ld is based on the standard GNU ld...

I was talking mainly about source documentation, not user documentation.
The user documentation for `ld' is actually quite good.

> but free software is free software, and you have the source, as
> cryptic as it may be.

Uh, no offence, but this sounds to me like a cop-out: are you
suggesting that because it is free software, it doesn't matter if the
quality is poor?

(Thankfully the people at Cygnus who have responded to this thread
_don't_ have that attitude.)

-- 
Fergus Henderson <fjh@cs.mu.oz.au>   |  "I have always known that the pursuit
WWW: < http://www.cs.mu.oz.au/~fjh >   |  of excellence is a lethal habit"
PGP: finger fjh@128.250.37.3         |     -- the last words of T. S. Garp.
-
For help on using this list, send a message to
"gnu-win32-request@cygnus.com" with one line of text: "help".

Re: Nobody in the world understands Gnu's 'ld'.

[Pedro A. Aranda Gutiirrez]

Fergus Henderson wrote:
> 
> Ian Lance Taylor wrote:
> >
> > Let's not get carried away here.  I understand the linker perfectly
> > well, and so do a number of other people.
> [...]
> > In fact, BFD works quite well.
> [...]
> However, let's not forget the point either: the GNU ld code
> is poorly structured and poorly documented.

Yes, I'd not be as mild as Fergus. I went through the same sorrows as
Jacob Navia when trying to understand the DLLTOOL source. It was 
'somehow' documented and completely unstructured, ergo not
understandable.

> Regardless of what happens with BFD, Cygnus ought to ensure that
> whatever code they write is well documented and properly structured.

This is something I learnt years ago in University and even my
personal 'quick-hacks' follow this philosophy. It really pays off.

> > I'd love to have some documentation if you care to write some and
> > contribute it.  This is, after all, free software.  It improves by
> > contributions.

Contributions sold afterwards by Cygnus. Forgive me, but if my
work is going to produce benefits, they should be for me and not
for someone else. I'm no DOn Quijote.

Ergo => all this commercial licensing stuff of Cygnus has somehow
rarified the atmosphere of FSF'ish software (that's at least my 
feeling and my VERY personal opinion)

-- 

     +--------------------------------------------------------+
     |  ####   Pedro Andres Aranda Gutierrez                  |
     |  ####                                                  |
     |  ####   Telefonica I+D;  Network Interconnection Div.  |
     |  ====   C./ Emilio Vargas, 6    E-28043 Madrid, Spain  |
     |  ====   e-mail : paag@tid.es                           |
     |  ====   Tlf 34-1-337 47 02      FAX 34-1-337 45 02     |
     +--------------------------------------------------------+
-
For help on using this list, send a message to
"gnu-win32-request@cygnus.com" with one line of text: "help".

Re: Nobody in the world understands Gnu's 'ld'.

[Ian Lance Taylor]

   Date: Wed, 26 Mar 1997 15:13:49 +0100
   From: "Pedro A. Aranda Guti\irrez" <paag@tid.es>

   > > I'd love to have some documentation if you care to write some and
   > > contribute it.  This is, after all, free software.  It improves by
   > > contributions.

   Contributions sold afterwards by Cygnus. Forgive me, but if my
   work is going to produce benefits, they should be for me and not
   for someone else. I'm no DOn Quijote.

   Ergo => all this commercial licensing stuff of Cygnus has somehow
   rarified the atmosphere of FSF'ish software (that's at least my 
   feeling and my VERY personal opinion)

Don't get confused.  BFD, gas, ld, the binutils, are all under the GPL
and always have been.  Any contributions you or anybody chooses to
make will be made under the GPL, will require a copyright assignment
to the Free Software Foundation, and will be included in future
binutils net releases for anybody to use.

The commercial licensing stuff applies only to the gnu win32 library
itself, which is copyrighted by Cygnus.  It does not apply to the
binutils.

On another topic, to quote you: ``if my work is going to produce
benefits, they should be for me and not for someone else. I'm no DOn
Quijote.''  I'm sorry you feel that way.  If you are using the GNU
binutils, or any FSF software, or indeed the GPL version of gnu-win32
itself, then you are benefitting from the work of people who are
rather less selfish than you seem to be.

I've been working in free software for several years now, starting
some years before I joined Cygnus.  I would certainly say ``if my work
is going to produce benefits, they should be for me.''  I don't work
out of altruism.  However, I would never say that the benefits should
not be for someone else as well.

Ian
-
For help on using this list, send a message to
"gnu-win32-request@cygnus.com" with one line of text: "help".

Commercial Licensing

[David Essex]

Ian Lance Taylor <ian@cygnus.com> wrote:

>BFD, gas, ld, the binutils, are all under the GPL
>and always have been.  Any contributions you or anybody chooses to
>make will be made under the GPL, will require a copyright assignment
>to the Free Software Foundation, and will be included in future
>binutils net releases for anybody to use.
>
>The commercial licensing stuff applies only to the gnu win32 library
>itself, which is copyrighted by Cygnus.  It does not apply to the
>binutils.
Commercial licensing ?
The cygnus gnu-win32 web page says that this is free software.
If win32 library is part of gnu why do you need a commercial license ?
Could some one expand on this ? 

David


-
For help on using this list, send a message to
"gnu-win32-request@cygnus.com" with one line of text: "help".

Re: Commercial Licensing

[Jim Balter]

David Essex wrote:
> 
> Ian Lance Taylor <ian@cygnus.com> wrote:
> 
> >BFD, gas, ld, the binutils, are all under the GPL
> >and always have been.  Any contributions you or anybody chooses to
> >make will be made under the GPL, will require a copyright assignment
> >to the Free Software Foundation, and will be included in future
> >binutils net releases for anybody to use.
> >
> >The commercial licensing stuff applies only to the gnu win32 library
> >itself, which is copyrighted by Cygnus.  It does not apply to the
> >binutils.
> Commercial licensing ?
> The cygnus gnu-win32 web page says that this is free software.
> If win32 library is part of gnu why do you need a commercial license ?
> Could some one expand on this ?


In addition to the GPL, Cygnus offers cygwin.dll under a restricted
license to commercial clients who wish to use it without sharing their
own sources.  As the owner, Cygnus has every legal right to do this.
Whether it is consistent with the spirit of the GPL is another matter.
There was a long, heated debate on the mailing list after Cygnus
posted a press release announcing their intentions; no sense in
repeating it.

Note that many libraries, such as glibc, are released under the LGPL,
not the GPL, implicitly allowing commercial users to do what commercial
users of cygwin must pay Cygnus for a license to do.  Cygnus
intentionally used the GPL rather than the LGPL for just this reason.

--
<J Q B>
-
For help on using this list, send a message to
"gnu-win32-request@cygnus.com" with one line of text: "help".

Re: Commercial Licensing

[Geoffrey Noer]

> The cygnus gnu-win32 web page says that this is free software.
> If win32 library is part of gnu why do you need a commercial license ?
> Could some one expand on this ? 

I just expanded the explanation for this a bit on the main WWW page.
Hopefully it will cut down on the amount of mail on this list that
pertains to this subject.

-- 
Geoffrey Noer
noer@cygnus.com
-
For help on using this list, send a message to
"gnu-win32-request@cygnus.com" with one line of text: "help".

Re: Nobody in the world understands Gnu's 'ld'.

[Ian Lance Taylor]

   From: Fergus Henderson <fjh@cs.mu.oz.au>
   Date: Wed, 26 Mar 1997 18:17:04 +1100 (EST)

   > Mind you, I'm not going to defend the way that BFD is written.
   > [...] I've tried to clean up some of the more egregious
   > problems.  Unfortunately, the cost of rewriting BFD is high.

   Right.  So what is the solution?  Well, in the case of BFD, perhaps the
   damage is already done -- the cost would have been a lot cheaper if it
   was done right in the first place.  However, even now, Cygnus should
   seriously consider spending the money to improve the quality of their
   existing source code, because it may be a *good investment*.

   Regardless of what happens with BFD, Cygnus ought to ensure that
   whatever code they write is well documented and properly structured.
   This will result in products that are easier to maintain, easier
   to extend, and as a result in the long term the products will be better.

   > I'd love to have some documentation if you care to write some and
   > contribute it.  This is, after all, free software.  It improves by
   > contributions.

   Documentation should not be an after-thought.  If Cygnus thinks that
   it can economize by not bothering with documentation or not bothering
   to write properly structured code, then they are wrong -- it may result
   in some short-term gains, but in the long run it will cost them a lot.
   It is much more difficult (and expensive) for someone to come along
   afterwards and write documentation than for the person doing the
   original work to write the documentation properly in the first place.

I'll note that I agree with all of this.  In particular, we've
certainly discussed whether rewriting BFD is a good investment or
not.  There is no obvious right answer.

People may think that Cygnus is a large software company with hundreds
of programmers designing products.  This is not the case.  It was even
less the case when BFD and the linker were written.  At that time,
Cygnus was a handful of programmers working with free software and
struggling to succeed by meeting customer demands very quickly.  It's
easy to second guess the decisions made at that time.  In fact,
though, you weren't there, and neither was I.  Programming decisions
are not made in an academic environment.  They are made in the real
world, under the pressure of time and money.

Ian
-
For help on using this list, send a message to
"gnu-win32-request@cygnus.com" with one line of text: "help".

Re: Mr Taylor surely understands ld: a correction to my previous post

[Ian Lance Taylor]

In cygnus.gnu-win32 root@jacob.remcomp.fr writes:

[ Various complaints about modularity and the like which I am not
  going to address.  Different people can reasonably have different
  opinions on these issues.  ]

>I still remain convinced that only Steve can fix this. It is a pity that he
>is gone. This means that this problem will remain as it is in the foreseeable
>future.

I just couldn't let this comment pass, though.  Steve is a great guy,
and a friend, but he is not the only person who can work on the
linker.  In fact, when we did the last major overhaul of the linker,
implementing the interface documented in bfd/linker.c, he designed it,
but I wrote it.  I understand the linker as well as he does.

In fact, the notion that only one person can work on a particular
program is nonsense.  I've never seen a useful program that I could
not understand and modify, if I was willing to take the time.  (This
is not meant as a challenge!)

Whether whatever Windows linker problem there may be will be fixed is
a different issue.  Steve used Windows, and wrote the original
gnu-win32 library, and cared about making the linker do the right
thing under Windows.  I don't use Windows, and although I would be
happy to help anybody fix any possible problems of the linker under
Windows insofar as I am able, I'm not likely to do anything about it
myself.  I have no idea what Cygnus's plans are in regards to the
linker under Windows.  I have no idea whether there really are any
linker problems, or how serious they are if they exist.

Ian
-
For help on using this list, send a message to
"gnu-win32-request@cygnus.com" with one line of text: "help".

RE: Mr Taylor surely understands ld: a correction to my previous post

[dahms]

Hi Jacob, you wrote:

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

What is an S-record, please?

: But WHY do we have to put the convertor and the linker in the SAME PROGRAM!!!
: In my view of things, it would be much better to have an easy to understand
: convertor to be used by systems programmers when they need S records, than
: to overload the linker with YET ANOTHER LEVEL OF COMPLEXITY!!!

In the same program, they can't get out-of-sync, when it's updated.
And nowadays, only the needed stuff is paged in.


Bye, Heribert (dahms@ifk20.mach.uni-karlsruhe.de)
-
For help on using this list, send a message to
"gnu-win32-request@cygnus.com" with one line of text: "help".

Re: Mr Taylor surely understands ld: a correction to my previous post

[Christoph Kukulies]

dahms@ifk20.mach.uni-karlsruhe.de writes:
> Hi Jacob, you wrote:
> 
> : 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.
> 
> What is an S-record, please?

e.g. Motorola S-Records. An ASCII readable format for downloading
into embedded systems or EPROM burning. Intel had these :-records,
I believe. First appeared in 1975. Someone taking part
in a linker discussion oughta know what it is :->

> 
> : But WHY do we have to put the convertor and the linker in the SAME PROGRAM!!!
> : In my view of things, it would be much better to have an easy to understand
> : convertor to be used by systems programmers when they need S records, than
> : to overload the linker with YET ANOTHER LEVEL OF COMPLEXITY!!!
> 
> In the same program, they can't get out-of-sync, when it's updated.
> And nowadays, only the needed stuff is paged in.
> 
> 
> Bye, Heribert (dahms@ifk20.mach.uni-karlsruhe.de)
> -
> For help on using this list, send a message to
> "gnu-win32-request@cygnus.com" with one line of text: "help".

-- 
--Chris Christoph P. U. Kukulies kuku@gil.physik.rwth-aachen.de
-
For help on using this list, send a message to
"gnu-win32-request@cygnus.com" with one line of text: "help".