Through circumstances beyond my control *cough* I've recently had to write some software in Borland C++ Builder 6 - now one of the libraries that I need I've created with cygwin / MingW; however, converting the .LIB created by dlltool for use with Borland (COFF2OMF) doesn't exactly work as it's supposed to - specifically, COFF2OMF is mistaking the stub file that dlltool creates for the actual DLL it has to load; Let me say first, though, that this is probably more of an error on the side of Borland than it is on that of dlltool, so I'm not expecting you to actually incorporate this patch into the current codebase (or at least not in it's current form) - but I thought I'd point it out here anyway and share my experiences, so that others that run into the same problems can have some use for it. Having said that, I've added a simple option to dlltool to indicate it should just use the dll_name variable as the stub filename, which seems to do the trick just perfectly, albeit in a rather dirty way ;-) The option and it's description should probably be changes aswell - I don't think it should mention Borland specifically, and right now it's suggesting it will create a Borland compatible library (OMF) .. I'm creating the DLL, the .LIB and the BCPP .LIB (COFF2OMF) like so: g++ -c test.cpp dlltool --bcpp-implib --add-underscore --dllname test.dll \ -e exports.o -l test.lib test.o g++ -mdll -mno-cygwin test.o exports.o -o test.dll coff2omf -q test.lib test_bcpp.lib Which creates a .LIB that still works with at least GCC (I haven't tried it with VC++) and of course now works with BCPP. Note that the --add-underscore is needed by BCPP, so perhaps it should be impliclity enabled by the --bcpp-implib option (though perhaps that behavior can be turned off in COFF2OMF) The patch is against dlltool 2.15.94 (20041229), which is supplied with cygwin - but ViewCVS reveals that the behavior hasn't seemed to have changed in later versions (but then I haven't actually tried it, so I could be wrong - or maybe I'm approaching the whole thing incorrectly to begin with ;-)) Anyway, this patch fixes my problems; I hope can be useful to others aswell. Kind regards, Jasper van Veghel
Created attachment 486 [details] dlltool import library compatibility with BCPP
Oh, the attachment of course depends on dll_name being relative to the actual path of the DLL (since it tries to open it) - that should probably be looked at.
.. and then it only seems to work if there's only one symbol being exported; otherwise it'll try to create and subsequently open the same file multiple times - still, the idea is there. I can't quite seem to pin-point exactly where the abfd filename gets written to the library (or stored in the archive to be written later - maybe in the BFD code?) - but it'll do, for now, for my intents and purposes :-)
Thanks for your patch -- and to think of archiving your discussion in the bug tracking system! I think it is worth proposing that it be incorporated into the mainline tree, however for a patch of this size that adds a new feature, it will be necessary to complete FSF paperwork. You should send the patch to binutils@ and see where it goes from there.