Subject: Re: Linker switches [ was: Re: API's that certainly do work. ]
From: [email-masked]

1 Apr 1997 19:10:37 -0800
Approved: [email-masked]
Distribution: cygnus
Message-ID: <[email-masked]>
Original-From: [email-masked]
Original-From: [email-masked]
Original-To: [email-masked]
Original-Cc: [email-masked]
X-Sun-Charset: US-ASCII
Original-Sender: [email-masked]

Geoffrey Noer wrote:

> The .idata3 terminator isn't automatically produced by any of the tools,
> because it was hard to integrate this functionality into ld/dlltool
> and/or because nobody has spent the time to do so.

Actually, it's pretty trivial, so I suppose it is because nobody had spent
the time.  I am currently working on getting dlltool and ld to interwork
with MSVC LINK & friends.  Currently, I have made a couple of small changes
to ld that get it to understand .lib files produced by MSVC.  There do seem
to be some problems with the communal data settings produced by MSVC (or
at least in the .lib files shipped with it).  The flags are interpreted by
ld in such a way that it sees duplicated segments when I don't think it
should be.  I'm still looking into this.

I have also modified dlltool to remove the need to generate a .s file
and assemble it, but to instead generate the .o files directly from the
appropriate BFD calls.  Along the way, I produce a file that resolves the
__NULL_IMPORT_DESCRIPTOR symbol and produces an import descriptor terminator
in .idata$3.  It seems that for dlltool to produce a .lib file that is
usable with MS LINK, the various entries in the archive must have the
same name.  This is annoyingly difficult to achieve with BFD, unless there's
a trick somewhere.  I can change the filename member of the archive name,
but the file descriptor caching needs the old filename to re-open the file
when writing out the archive...

> Producing dlls is currently much more clumsy than I think it needs to be.
> (I'd like to do away with dlltool entirely and have the functionality
> included in ld but I don't know how practical this would be).  Regardless,
> the dll building process is something I think is important to improve.

I'd have to agree with this.  It would also be very nice for ld to procude
the .reloc section directly instead of having to make a pre-pass and working
with dlltool to produce it.  Conceptually it isn't difficult, but there may
be some design issues with ld that make it difficult (the size of all segments
[including .reloc] must be known before output is started, but the .reloc
data is generated as a byproduct of the output processing, I think)  I
don't think that it is necessary to eliminate dlltool, but if the process
for creating a dll is made reliable and more intuitive, I'm all for it.

Now, questions for the list:

Is there anybody else working to the same goal (interworking with the MSVC
files/tools)?  Does anybody have a good handle on the meanings of the
communal data flags in MS .lib files?  There is code in ld that tries to
translate them into BFD's internal flags, but ld just compares segment
names although I believe that MS may be thinking file(segment) names
should be compared for duplicates..

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