Subject: Re: bfd, ld, and dlltool patches
From: [email-masked]

17 Jul 1997 20:56:43 -0700
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]

Please forgive the repeat if this is one, but I emailed this yesterday
morning and still have not seen it show up on the mailinglist....

I have been doing some work in my spare time (actually it was a while ago
on b17.1) to build a cross-compiler environment to generate NT code on a
Sun and interwork with MS DLLs.  To this end, I have about 350 lines of
patches to bfd and ld files, and 1200 lines of patches to dlltool.  These
have been forwarded to the b18 versions, although I haven't had time to
do any further development.

At this point, I can link with many of the microsoft .lib libraries.  The
remaining problem seems to be in handling some of the segment types where
ld complains that it is ignoring multiple instances of a segment, aparently
because of a mis-interpretation of communil data header information.   I
can produce a .lib that is almost acceptable to MS LINK, but it seems that
LINK wants the file names inside the archive to be identical, unlike the
dt0.o, dt1.o, etc. files produced by dlltool.  There isn't an obvious way
to get bfd to produce an archive with internal file names to be the same
even though it can handle this case in an existing archive just fine.  Perhaps
playing with storing the files in memory instead of in disk files would
be appropriate here, since the problem seems to be in that aspect.

Most of the changes to dlltool were to (nearly) eliminate the use of the
assembler to produce the .o files and to simply write the .o files directly
with bfd.  I have converted all the code to deal with generating the import
tables, but have not yet attacked the export tables.  I also generate an
import table terminator that is compatible with the MS .libs, so the
fixup.c kludges should no longer be necessary.

My question here is, does the list want to see the patches posted here or not?
If not, what mechanism would be appropriate?  Since b19 is forthcoming and
some of these changes may be useful for that, I'd like to get some of these
changes submitted for consideration by cygnus, and perhaps save them some
work if they haven't already done equivalent work.

The context diff is 1419 lines long...

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