From mboxrd@z Thu Jan 1 00:00:00 1970 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 Message-id: References: <199707161522.JAA04092@chorus.dr.lucent.com> X-SW-Source: 1997-07/msg00395.html In article < 199707161522.JAA04092@chorus.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".