Alexandre, (I hope I'm not being direspectful)
your patch (561a3e643ea8b35adfc032d3afa979c622fcec23) did not work.
I know that there is no Cygwin VM in WineTestBot yet to test such a patch. I think I was not very clear about the issue on cygwin so this time I'll be more .. verbose.
Here is the relevant call stack of winegcc on cygwin :
1093 _int main(int argc, char **argv) 1373 _ else if (linking) build(&opts); 559 _static void build(struct options* opts) 722 _ strarray_add(link_args, mingw_unicode_hack(opts)); 547 _static const char *mingw_unicode_hack( struct options *opts ) 556 _ return compile_to_object( opts, main_stub, NULL ); 457 _static const char* compile_to_object(struct options* opts, const char* file, const char* lang) 470 _ compile(&copts, lang); 309 _static void compile(struct options* opts, const char* lang) ...here your patch didn't change anything because it hasn't been read 453 _ spawn(opts->prefix, comp_args, 0);
so winegcc [1] calls ccache gcc-4 -D__WINE__ -c -o cmd.exe-2VhiZq-6BngcL.o cmd.exe-2VhiZq.c -I../../include that leads to
cmd.exe-2VhiZq.c: In function ‘main’: cmd.exe-2VhiZq.c:5: error: ‘__wargv’ undeclared (first use in this function) cmd.exe-2VhiZq.c:5: error: (Each undeclared identifier is reported only once cmd.exe-2VhiZq.c:5: error: for each function it appears in.) winegcc: ccache failed make: *** [cmd.exe] Error 2
To fix it, we need to add msvcrt include (not to link with msvcrt : it's a .o)
ccache gcc-4 -D__WINE__ -c -o cmd.exe-iqnSoR-q4unrB.o cmd.exe-iqnSoR.c -I../../include -I../../include/msvcrt/ succeeds.
At this point, we return from mingw_unicode_hack to line 722.
And winegcc goes on:
779 _ if (!opts->shared && (opts->use_msvcrt || opts->unicode_app)) strarray_add(link_args, "-lmsvcrt"); ...your patch 781 _if (res_o_name) compile_resources_to_object( opts, resources, res_o_name ); ...the previous line works, no errors but 783 _ spawn(opts->prefix, link_args, 0); ..fails
Indeed, the linker [2] wants to link with msvcrt but don't know where the library is :
/usr/lib/gcc/i686-pc-cygwin/4.3.4/../../../../i686-pc-cygwin/bin/ld: cannot find -lmsvcrt collect2: ld returned 1 exit status winegcc: ccache failed make: *** [cmd.exe] Error 2
Finally, adding -L option [3], all's right.
Sorry for this looong mail. I think I won't send a patch but if you ask me. So thanks again and have a nice week end.
---
[1] ../../tools/winegcc/winegcc -B../../tools/winebuild --sysroot=../.. -mconsole -municode batch.o builtins.o directory.o wcmdmain.o Cs.res Da.res De.res En.res Es.res Fr.res It.res Ja.res Ko.res Lt.res Nl.res No.res Pl.res Pt.res Ru.res Si.res Tr.res wcmdrc.res -o cmd.exe -lshell32 -luser32 -ladvapi32 -lkernel32 -lwine ../../libs/port/libwine_port.a
[2] ccache gcc-4 -mconsole -o cmd.exe cmd.exe-iqnSoR-q4unrB.o -L../../dlls -L../../libs/wine batch.o builtins.o directory.o wcmdmain.o cmd.exe-XiDu0i.res.o -L../../dlls/shell32 -lshell32 -L../../dlls/user32 -luser32 -L../../dlls/advapi32 -ladvapi32 -L../../dlls/kernel32 -lkernel32 -L../../libs/wine -lwine -L../../libs/port -lwine_port -L../../dlls/winecrt0 -lwinecrt0 -lmsvcrt
[3] ccache gcc-4 -mconsole -o cmd.exe cmd.exe-mfRWfQ-uwdRsu.o -L../../dlls -L../../libs/wine batch.o builtins.o directory.o wcmdmain.o cmd.exe-1DumDa.res.o -L../../dlls/shell32 -lshell32 -L../../dlls/user32 -luser32 -L../../dlls/advapi32 -ladvapi32 -L../../dlls/kernel32 -lkernel32 -L../../libs/wine -lwine -L../../libs/port -lwine_port -L../../dlls/winecrt0 -lwinecrt0 -lmsvcrt -L../../dlls/msvcr
GOUJON Alexandre ale.goujon@gmail.com writes:
To fix it, we need to add msvcrt include (not to link with msvcrt : it's a .o)
ccache gcc-4 -D__WINE__ -c -o cmd.exe-iqnSoR-q4unrB.o cmd.exe-iqnSoR.c -I../../include -I../../include/msvcrt/ succeeds.
At this point, we return from mingw_unicode_hack to line 722.
And winegcc goes on:
779 _ if (!opts->shared && (opts->use_msvcrt || opts->unicode_app)) strarray_add(link_args, "-lmsvcrt"); ...your patch 781 _if (res_o_name) compile_resources_to_object( opts, resources, res_o_name ); ...the previous line works, no errors but 783 _ spawn(opts->prefix, link_args, 0); ..fails
Indeed, the linker [2] wants to link with msvcrt but don't know where the library is :
/usr/lib/gcc/i686-pc-cygwin/4.3.4/../../../../i686-pc-cygwin/bin/ld: cannot find -lmsvcrt collect2: ld returned 1 exit status winegcc: ccache failed make: *** [cmd.exe] Error 2
Finally, adding -L option [3], all's right.
You can't add include or lib options, that will break the Mingw build.
Le 03/20/10 15:57, Alexandre Julliard a écrit :
You can't add include or lib options, that will break the Mingw build.
And what about #ifdef __CYGWIN__ ? It sounds ugly but ... why not ?
Thanks
GOUJON Alexandre ale.goujon@gmail.com writes:
Le 03/20/10 15:57, Alexandre Julliard a écrit :
You can't add include or lib options, that will break the Mingw build.
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.
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
On Mon, Mar 22, 2010 at 12:47 PM, Steven Edwards winehacker@gmail.com wrote:
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.
Sorry I realize that last sentence ran on to hell. What I mean is, on the cygwin build, require mingw to be there for the compilation and invocation of winegcc which is a wrapper around cygwin-gcc. Wine dlls, programs, server, etc all still would be linking to the cygwin1 runtime but would in no way be dependent on Windows msvcrt only Wine's and the environment cygwin1.dll
Thanks
Den 2010-03-22 17:47 skrev Steven Edwards:
On Sat, Mar 20, 2010 at 2:49 PM, Alexandre Julliardjulliard@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
Peter Rosin schrieb:
Den 2010-03-22 17:47 skrev Steven Edwards:
On Sat, Mar 20, 2010 at 2:49 PM, Alexandre Julliardjulliard@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.
- Stick with gcc-3 and -mno-cygwin.
Or, if gcc-4 is required,
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.
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" ???
On Tue, Mar 23, 2010 at 4:17 AM, Peter Rosin peda@lysator.liu.se wrote:
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?)
I think I missunderstood the original problem with winegcc looking for the entry point but the ultimate problem is still the same which is as you pointed out which is linking to both msvcrt and the cygwin runtime won't work. I think it could work if you don't actually use the system msvcrt but instead use the wine msvcrt which is dependant on the cygwin runtime.
Sorry for the delay,
First of all, I would like to explain why I tried to compile wine on cygwin.
My first goal was to help wine as some of you improve wine on different systems (native 64 bits. WOW...). I knew that wine compiled well on MinGW but I'm not using it. Cygwin is, on my mind, simpler to set up and to use. If you want git or gdb you have to click "next" several times and that's done. On MinGW, there is no bash or you have to install MSYS (from what I remember) : it's painful to have a basic system. But I'm not here to argue...
The previous answers of this topic made me wonder "what do we know ?". Either we want to build wine on cygwin (depending on cygwin1.dll) or to build it as a native Windows app. The first approach means that we're going to build a windows emulator on an emulator of unix system on a computer running Windows OS. (I *know* that wine stands for Wine Is Not An Emulator but you understood what I mean) Does it make any sense ?
And the second one is building wine with MinGW.
-- But I agree we should replace "-no-cygwin" by something more .. meaningful.
It's not up to me to say what we should do, I'm only telling you my opinion.
Comments are, as always, welcome.
-
Alexandre Julliard -
André Hentschel -
GOUJON Alexandre -
Peter Rosin -
Steven Edwards