From mboxrd@z Thu Jan 1 00:00:00 1970 From: Christoph Kukulies To: marcus@bighorn.dr.lucent.com Cc: gnu-win32@cygnus.com, noer@cygnus.com Subject: Re: bfd, ld, and dlltool patches Date: Wed, 06 Aug 1997 09:50:00 -0000 Message-id: <19970806165229.35697@gil.physik.rwth-aachen.de> References: <199707181824.MAA06085@chorus.dr.lucent.com> X-SW-Source: 1997-08/msg00112.html On Fri, Jul 18, 1997 at 12:24:20PM -0600, marcus@bighorn.dr.lucent.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@cygnus.com" with one line of text: "help". -- Chris Christoph P. U. Kukulies kuku@gil.physik.rwth-aachen.de - For help on using this list (especially unsubscribing), send a message to "gnu-win32-request@cygnus.com" with one line of text: "help".