This is the mail archive of the
cygwin@cygwin.com
mailing list for the Cygwin project.
Re: linking with non-cygwin dll
On Thu, Jul 24, 2003 at 12:53:35PM +0100, Elfyn McBratney wrote:
>> so apparently the printf in the DLL doesn't work - I don't know why, though.
>> Perhaps someone else can figure that one out..
> It's because there's two printf symbols (the MSVCRT one and the Cygwin one).
That's kinda what I thought, but it would have made more sense if it had just
quit and died, or if it had used the printf from either one of the CRTs:
apparently, not knowing which one to take makes it not take either one..
Also interesting: I apparently can't trace into printf - not even if it's all
the program does and my cygwin1.dll contains the debugging symbols as it's
upposed to (current CVS build) - I just checked with `nm -a /bin/cygwin1.dll |
grep printf` and printf is in there (probably the newlib version):
610a8450 T _printf
YA interesting fact: dynamically loading doesn't help.
I've uploaded a new STC:
f31c53bf9d9184988ea8a65b5d5465fc *crosslink.tgz
http://blytkerchan.chez.tiscali.fr/crosslink.tgz
running make creates a MinGW DLL (dll.dll); two Cygwin apps: cygtest.exe and
cygtestdyn.exe; and two MinGW apps: mintest.exe and mintestdyn.exe.
cygtest.exe should still not work, as it is the same as before;
cygtestdyn.exe should work, as it does a LoadLibrary and should not share its
printf with the Cygwin program - it doesn't work either.
The two min* versions work, and use the printf provided by msvcrt.dll
hmm..
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/