Re: Using gnu win32 compiled libraries with MS Visual C++?

Re: Using gnu win32 compiled libraries with MS Visual C++?

[marcus]

> 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@cygnus.com" with one line of text: "help".

Using gnu win32 compiled libraries with MS Visual C++?

[Pete Magsig]

Does anyone out there have any experience using gnu win32 compiled
libraries
under visual C++ apps? We have a situation where one development group
does most
of their work on Suns in a cygnus/gnu environment but is interested in
compiling some
of their libraries for another group that uses VC++ exclusively.

It is not feasible for the Sun-based group to migrate to NT, nor is it
practical
for the VC++ group to migrate to Suns (for business reasons). Can gnu
win32
act as an effective bridge if the Sun group is the supplier and the VC++
group
the customer?

Pete


P.S. I would appreciate it if my question doesn't generate the usual
"GNU Rules, Microsoft Sucks" and "Why use gnu when you can use the
'transcendent' Visual C++?" kind of rhetoric. I really just want to know
if anyone out there has
done this. Thanks in advance for your restraint.

-
For help on using this list (especially unsubscribing), send a message to
"gnu-win32-request@cygnus.com" with one line of text: "help".