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, [EMAIL PROTECTED] 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/
