From: marcus AT bighorn DOT dr DOT lucent DOT com Subject: Re: Linker switches [ was: Re: API's that certainly do work. ] 1 Apr 1997 19:10:37 -0800 Approved: cygnus DOT gnu-win32 AT cygnus DOT com Distribution: cygnus Message-ID: <199704011734.KAA02392.cygnus.gnu-win32@chorus.dr.lucent.com> Original-From: marcus AT drmail DOT dr DOT lucent DOT com Original-From: marcus AT drmail DOT dr DOT lucent DOT com Original-To: noer AT cygnus DOT com Original-Cc: gnu-win32 AT cygnus DOT com X-Sun-Charset: US-ASCII Original-Sender: owner-gnu-win32 AT cygnus DOT com Geoffrey Noer wrote: > The .idata3 terminator isn't automatically produced by any of the tools, > because it was hard to integrate this functionality into ld/dlltool > and/or because nobody has spent the time to do so. Actually, it's pretty trivial, so I suppose it is because nobody had spent the time. I am currently working on getting dlltool and ld to interwork with MSVC LINK & friends. Currently, I have made a couple of small changes to ld that get it to understand .lib files produced by MSVC. There do seem to be some problems with the communal data settings produced by MSVC (or at least in the .lib files shipped with it). The flags are interpreted by ld in such a way that it sees duplicated segments when I don't think it should be. I'm still looking into this. I have also modified dlltool to remove the need to generate a .s file and assemble it, but to instead generate the .o files directly from the appropriate BFD calls. Along the way, I produce a file that resolves the __NULL_IMPORT_DESCRIPTOR symbol and produces an import descriptor terminator in .idata$3. It seems that for dlltool to produce a .lib file that is usable with MS LINK, the various entries in the archive must have the same name. This is annoyingly difficult to achieve with BFD, unless there's a trick somewhere. I can change the filename member of the archive name, but the file descriptor caching needs the old filename to re-open the file when writing out the archive... > Producing dlls is currently much more clumsy than I think it needs to be. > (I'd like to do away with dlltool entirely and have the functionality > included in ld but I don't know how practical this would be). Regardless, > the dll building process is something I think is important to improve. I'd have to agree with this. It would also be very nice for ld to procude the .reloc section directly instead of having to make a pre-pass and working with dlltool to produce it. Conceptually it isn't difficult, but there may be some design issues with ld that make it difficult (the size of all segments [including .reloc] must be known before output is started, but the .reloc data is generated as a byproduct of the output processing, I think) I don't think that it is necessary to eliminate dlltool, but if the process for creating a dll is made reliable and more intuitive, I'm all for it. Now, questions for the list: Is there anybody else working to the same goal (interworking with the MSVC files/tools)? Does anybody have a good handle on the meanings of the communal data flags in MS .lib files? There is code in ld that tries to translate them into BFD's internal flags, but ld just compares segment names although I believe that MS may be thinking file(segment) names should be compared for duplicates.. marcus hall Lucent Technologies - For help on using this list, send a message to "gnu-win32-request AT cygnus DOT com" with one line of text: "help".