From: marcus AT bighorn DOT dr DOT lucent DOT com Subject: Re: Using gnu win32 compiled libraries with MS Visual C++? 10 Nov 1997 07:39:27 -0800 Message-ID: <199711101526.IAA19241.cygnus.gnu-win32@chorus.dr.lucent.com> To: gnu-win32 AT cygnus DOT com, magsig AT acuson DOT com > Can gnu > win32 > act as an effective bridge if the Sun group is the supplier and the VC++ > group > the customer? > > Pete Are you wanting to create a static-linked library, or a DLL? I think that a static-linked library is do-able with the current tools with very little problems. However, if you want to produce a DLL, then there is at least one thing that I don't know what the best way to address is... Actually generating the DLL itself is not too bad, but generating the .lib file that the VC++ group will need to link against is a different matter. With cygwin32, you use "dlltool" to produce this file, and it is an archive of object modules. These object modules produce a jump table for calling the DLL as well as the import table that the system uses to resolve the addresses. It contains "dh.o" and "dt.o" as header and trailer modules to build the import table. Additionally, it contains modules named "d0.o", "d1.o", ..., one module for each function in the DLL. Now, the problem is that the VC++ LINK command seems to depend on these files all having the same name within the .lib archive. Typically, inside "file.lib", they will be named "file.dll", although it seems to not matter what the name is, so long as it is the same name. It appears that LINK considers the modules to be part of a larger whole if they all have the same name. Anyhow, the problem is that generating an archive like this is very difficult in dlltool, since the BFD library that manages binary files cannot readily generate such an archive. It can manipulate an archive with members having the same name just fine, but generating it in the first place is difficult because it initially holds the file contents in real files with the given name and multiple files will overwrite each other. So, if you generate a DLL with cygwin32 and get the VC++ people to generate the .lib file themselves, it will likely all go just fine. It you need the Sun based people to generate the .lib files, then you're probably going to need to muck about in the BFD code. BTW, this all applies to "C" code only. If you're trying to share "C++" code, then it isn't nearly as nice a picture. The problem is that the name mangling schemes are different and there is no guarantee that the virtual function tables and other C++ constructs are implemented the same way. marcus hall Lucent Technologies - For help on using this list (especially unsubscribing), send a message to "gnu-win32-request AT cygnus DOT com" with one line of text: "help".