Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm
List-Subscribe: <mailto:cygwin-subscribe AT cygwin DOT com>
List-Archive: <http://sources.redhat.com/ml/cygwin/>
List-Post: <mailto:cygwin AT cygwin DOT com>
List-Help: <mailto:cygwin-help AT cygwin DOT com>, <http://sources.redhat.com/ml/#faqs>
Sender: cygwin-owner AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com
Delivered-To: mailing list cygwin AT cygwin DOT com
X-Authentication-Warning: localhost.localdomain: ronald set sender to blytkerchan AT users DOT sourceforge DOT net using -f
Date: Thu, 24 Jul 2003 11:44:47 +0200
From: Ronald Landheer-Cieslak <blytkerchan AT users DOT sourceforge DOT net>
To: vikram AT dontexist DOT com
Cc: cygwin AT cygwin DOT com
Subject: Re: linking with non-cygwin dll
Message-ID: <20030724094447.GB4123@linux_rln.harvest>
Mail-Followup-To: vikram AT dontexist DOT com, cygwin AT cygwin DOT com
References: <Pine DOT LNX DOT 4 DOT 50 DOT 0307232118220 DOT 14040-100000 AT hidis DOT cjb DOT net>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <Pine.LNX.4.50.0307232118220.14040-100000@hidis.cjb.net>
User-Agent: Mutt/1.4i
X-Disclaimer: I had nothing to do with it - I swear!
X-loop: linux_rln.harvest

On Wed, Jul 23, 2003 at 09:20:02PM -0700, vikram AT dontexist DOT com 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 
mutually exclusive. 

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
for JNI).

HTH

rlc

-- 

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/