On Sat, Mar 20, 2010 at 2:49 PM, Alexandre Julliard julliard@winehq.org wrote:
And what about #ifdef __CYGWIN__ ? It sounds ugly but ... why not ?
You can't use #ifdefs in winegcc. I suppose you could try to resolve __wargv dynamically at run-time.
I was wondering if it was possible under current cygwin to still install mingw that was a separate package from the cygwin-gcc.
Sorry for not asking sooner but I assume based upon prior emails we are going to end up linking msvcrt and cygwin1? Are you sure this is even going to work? When I've tried this in the past, which was years ago, the applications would either crash or behave unpredictably. I checked the cygwin faq and linking to both msvcrt and cygwin1 was still not supported but perhaps the FAQ is out of date. I am not sure what has changed and have just be cursory following this but it peaked my interest since it was stated that they removed the -mno-cygwin option.
Assuming 'bad things' still happen, I was thinking, could we make it work if we linked to msvcrt and then were able to use a wine build of our msvcrt which would forward functionality that it did not implement itself to cygwin1. I guess this is kind of how msvcrt/glibc work on Linux. More assumptions which may not matter but, I could see it still not working due to msvcrt perhaps being a 'KnownDLL' in recent windows (I am not sure if it is or if you can still use your own msvcrt). Also this whole idea would create a circular dependancy because we would have to build wine to be able to build winegcc,
My thinking was, if we require mingw on cygwin, then that would solve the winegcc problem and the rest of wine could be built including wine msvcrt, applications that linked to msvcrt would of course have to use Wine msvcrt because if they don't then we will get in to the situation of both c runtimes being invoked which I expect will still not end well.
Thanks