This is the mail archive of the mailing list for the Cygwin project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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

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




Unsubscribe info:
Problem reports:

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]