From mboxrd@z Thu Jan 1 00:00:00 1970 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 Message-id: <199707172128.PAA05413@chorus.dr.lucent.com> X-SW-Source: 1997-07/msg00409.html 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".