Re: linking with non-cygwin dll

[Ronald Landheer-Cieslak <blytkerchan at users dot sourceforge dot net>]

I've just tried the direct linking thing. My STC doesn't quite work as it 
should, but at least it doesn't actually die either..

The STC is available here:
6696e19e993e83606e205b5cbc2104fd *crosslink.tgz
http://blytkerchan.chez.tiscali.fr/crosslink.tgz

it contains a makefile and two sources - compile and run.
You should get:
$ make
gcc -mno-cygwin -g -o dll.dll -shared dll.c
gcc -g -o test.exe test.c dll.dll
$ ./test
12
13
$ echo $?
0

but I get:
$ make
gcc -mno-cygwin -g -o dll.dll -shared dll.c
gcc -g -o test.exe test.c dll.dll
$ ./test
13
$ echo $?
0

so apparently the printf in the DLL doesn't work - I don't know why, though.
Perhaps someone else can figure that one out..

HTH

rlc



On Thu, Jul 24, 2003 at 11:44:47AM +0200, Ronald Landheer-Cieslak wrote:
> On Wed, Jul 23, 2003 at 09:20:02PM -0700, vikram@dontexist.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/

-- 

--
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/