Mail Archives: cygwin/2003/07/24/07:33:19
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 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/
--
--
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/
- Raw text -