From:	kuku AT gilberto DOT physik DOT rwth-aachen DOT de (Christoph Kukulies)
Subject:	Re: bfd, ld, and dlltool patches
6 Aug 1997 15:38:11 -0700 :
Approved:	cygnus DOT gnu-win32 AT cygnus DOT com
Distribution:	cygnus
Message-ID:	<19970806165229.35697.cygnus.gnu-win32@gil.physik.rwth-aachen.de>
References:	<199707181824 DOT MAA06085 AT chorus DOT dr DOT lucent DOT com>
Mime-Version:	1.0
Original-To:	marcus AT bighorn DOT dr DOT lucent DOT com
Original-Cc:	gnu-win32 AT cygnus DOT com, noer AT cygnus DOT com
X-Mailer:	Mutt 0.75e
In-Reply-To:	<199707181824.MAA06085@chorus.dr.lucent.com>; from marcus@bighorn.dr.lucent.com on Fri, Jul 18, 1997 at 12:24:20PM -0600
Original-Sender:	owner-gnu-win32 AT cygnus DOT com

On Fri, Jul 18, 1997 at 12:24:20PM -0600, marcus AT bighorn DOT dr DOT lucent DOT com wrote:
> OK, well, I just saw the test message from this morning, but I haven't seen
> any sign of the two previous mailings of this message from Wednesday and
> Thursday.  If they did actually make it to the mailing list, I'm sorry for
> the repeat, and would somebody please tell me to stop! :-)
> 
> 
> 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.

I would like to see the patches posted, either as a gzipped/uuencoded
mail appendix or put up for ftp somewhere. 


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

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

- Raw text -