Verbose explanation about the cygwin issue

André Hentschel nerv at dawncrow.de
Tue Mar 23 09:59:17 CDT 2010


Peter Rosin schrieb:
> Den 2010-03-22 17:47 skrev Steven Edwards:
>> On Sat, Mar 20, 2010 at 2:49 PM, Alexandre
>> Julliard<julliard at 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.
> 
> Hi!
> 
> I don't know what you want to achieve, so I will just talk from the
> Cygwin/MinGW side and ignore the Wine side for a bit.
> 
> The gcc version 3 series in Cygwin included a switch -mno-cygwin which
> turner gcc into a MinGW tool chain. I.e. a cross compiler. The normal
> way to handle cross tools would be to name them i586-mingw32-gcc or
> something such. Since people apparently got confused and didn't
> realize that they were using a cross compiler when then typed -mno-cygwin
> it was decided that that option should be ditched for the gcc version
> 4 series in Cygwin, in favour of a properly named cross tool chain.
> The first part has been implemented (there's no -mno-cygwin option in
> Cygwin gcc-4) but unfortunately not the second.
> 
> So, users that need to use the MinGW compiler from Cygwin have some
> options.
> 
> 1. Stick with gcc-3 and -mno-cygwin.
> 
> Or, if gcc-4 is required,
> 
> 2. Build the cross tool chain manually. However, there might be
>    good reasons (such as obscure bugs) for an official package to
>    not be available yet.
> 
> 3. Wait for the official cross tool chain to be available.
> 
> So, you need to ask yourselves what you want to do. Do you want to
> build Cygwin dlls/executables (depends on Cygwin libc) or do you
> want to build MinGW dlls/executables (depends on msvcrt)?
> 
> Mixing is not supported, and if you do that anyway with anything
> sufficiently non-trivial you get to keep the pieces, so the
> suggestion to use -L/usr/lib/w32api -lmsvcrt with the native
> Cygwin gcc is not good even if it appears to work. (hmmm, was
> that even the suggestion?)
> 
> Cheers,
> Peter
> 

Maybe we should first remove every mno-cygwin stuff from wine to avoid confusion.
Just searching for an alternative name which states "use-wine-msvcrt" or "dont-use-native-crt".
What about "-use-winecrt" ???

-- 

Best Regards, André Hentschel



More information about the wine-devel mailing list