This is the mail archive of the
mailing list for the Cygwin project.
Re: linking with non-cygwin dll
- From: Ronald Landheer-Cieslak <blytkerchan at users dot sourceforge dot net>
- To: vikram at dontexist dot com
- Cc: cygwin at cygwin dot com
- Date: Thu, 24 Jul 2003 11:44:47 +0200
- Subject: Re: linking with non-cygwin dll
- References: <Pine.LNX.email@example.com>
On Wed, Jul 23, 2003 at 09:20:02PM -0700, firstname.lastname@example.org wrote:
> I maintain a unix program that links with a third party
> library that I dont have the source to. I now have to port my program
> to windows and was considering the cygwin route. The third party
> library is available for windows, but I learn from googling around
> that msvcrt.dll and the cygwin dll cannot coexist in the same
> executable. I dont know how the linking process works on windows, so I
> was wondering if the third party library could possibly have a msvcrt.dll
> dependency that would rule out cygwin for my port.
It's true that you can't link a single executable to both cygwin1.dll and
msvcrt.dll: both are (or act as) C runtime libraries and, as such, are
That doesn't mean you can't *use* the third-party non-Cygwin DLL: it just means
you're not using the same CRT.
The simplest & safest way to do what you're trying to do is using a LoadLibrary
on the DLL. That way, you're sure you only get the symbols you actually want
from the library and you don't have to worry about msvcrt.dll at all..
It should be possible (I think) to just link to the DLL (if you have the import
library for it), but I've never tried such a thing.
Remember, though, that msvcrt is not the only problem you might run into: the
calling conventions for the C functions must match (otherwise your application
will crash miserably) and, if you're using C++ functions, you're probably
completely out of luck as the name mangling done by g++ is not the same as the
one done by MSVC. I have no idea how that would interact with a LoadLibrary &
GetProcAddress combination, as I've never tried..
What I do know for sure is that, with a little care on the calling convention,
you can dynamically load a Cygwin DLL from within a non-Cygwin Windows
application - though you can't load the Cygwin1.dll itself like that because
it's been broken for a while now (PTC). I've used that technique a couple of
times already and have explained it on this list (see the archives and look
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: http://cygwin.com/problems.html