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/
