linking with non-cygwin dll

[Ronald Landheer-Cieslak]

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/