public inbox for cygwin@cygwin.com
 help / color / mirror / Atom feed
From: marcus@bighorn.dr.lucent.com
To: gnu-win32@cygnus.com
Cc: noer@cygnus.com
Subject: Re: bfd, ld, and dlltool patches
Date: Thu, 17 Jul 1997 20:26:00 -0000	[thread overview]
Message-ID: <199707172128.PAA05413@chorus.dr.lucent.com> (raw)

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

             reply	other threads:[~1997-07-17 20:26 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
1997-07-17 20:26 marcus [this message]
  -- strict thread matches above, loose matches on Subject: below --
1997-08-15 21:41 marcus
1997-07-18 11:25 marcus
1997-08-06  9:50 ` Christoph Kukulies
1997-07-16 13:45 marcus
1997-07-17 12:34 ` Chris Faylor

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=199707172128.PAA05413@chorus.dr.lucent.com \
    --to=marcus@bighorn.dr.lucent.com \
    --cc=gnu-win32@cygnus.com \
    --cc=noer@cygnus.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).