Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm List-Subscribe: List-Archive: List-Post: List-Help: , 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 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: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: 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/