Verbose explanation about the cygwin issue

[Peter Rosin]

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

-- 
They are in the crowd with the answer before the question.
 > Why do you dislike Jeopardy?