public inbox for cygwin@cygwin.com
 help / color / mirror / Atom feed
From: cgf@bbc.com (Chris Faylor)
To: gnu-win32@cygnus.com
Subject: Re: bfd, ld, and dlltool patches
Date: Thu, 17 Jul 1997 12:34:00 -0000	[thread overview]
Message-ID: <EDH9y9.70L@bbc.com> (raw)
In-Reply-To: <199707161522.JAA04092@chorus.dr.lucent.com>

In article < 199707161522.JAA04092@chorus.dr.lucent.com >,
 <marcus@bighorn.dr.lucent.com> wrote:
>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...

I'd be interested in seeing the changes.  I was interested in using ld
to link objects created by msvc++ but found that they confused gnu ld.
Maybe your changes will fix this.
-- 
http://www.bbc.com/	cgf@bbc.com			"Strange how unreal
VMS=>UNIX Solutions	Boston Business Computing	 the real can be."
-
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 12:34 UTC|newest]

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

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=EDH9y9.70L@bbc.com \
    --to=cgf@bbc.com \
    --cc=gnu-win32@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).