Hello Everyone, First I want to thank everyone for the help they have given me in dealing with my bad spelling, lack of grammer and not following the rules when working to get most of wine built for mingw. I'm trying to do a little house keeping with Wine and ReactOS and had a few changes/questions that could make my and the ReactOS teams life a little easyer with the port.
1. Can we set --disable-win16 CFLAGS=-DWINE_NOWINSOCK" to be default when building under Mingw? I tried to write a configure patch for this a while back but never could get the bastard to work. Once this option is removed all we will be left with is ./configure to configure wine for mingw. None of the WINE networking stuff will really work for anyone working with mingw and I dont expect that to change anytime soon. Without this flag anything that include winsock.h or winsock2.h will puke when building on Windows. I know that WINE on linux will need win16 for a while due to older installers that are 16bit but for the mingw port thats kind of not important.
2. Can we set a conditional option to not build winegcc and winewrap? These are not needed on Windows as they are only used to port mingw applications to winelib. Due to the use of Unixisms in these programs (fork, waitpid, etc) they wont build. Now I know we could stub fork and wrap waitpid to wait but its kind of pointless and I can see one day when someone will ask why these dont work on windows even though we build them. IMHO they just shouldnt get built for us.
winegcc.c: In function `spawn': winegcc.c:86: warning: implicit declaration of function `fork' winegcc.c:89: warning: implicit declaration of function `waitpid' winegcc.c:92: warning: implicit declaration of function `WIFEXITED' winegcc.c:92: warning: implicit declaration of function `WEXITSTATUS' gcc -DWINE_NOWINSOCK -Wall -mpreferred-stack-boundary=2 -gstabs+ -Wpointer-arith -o winegcc winegcc.o -L../libs/port -lwine_port winegcc.o(.text+0x1a3): In function `spawn': g:/src/wine-dev/wine/tools/winegcc.c:86: undefined reference to `fork' winegcc.o(.text+0x1d2):g:/src/wine-dev/wine/tools/winegcc.c:89: undefined refere nce to `waitpid' winegcc.o(.text+0x202):g:/src/wine-dev/wine/tools/winegcc.c:92: undefined refere nce to `WIFEXITED' winegcc.o(.text+0x211):g:/src/wine-dev/wine/tools/winegcc.c:92: undefined refere nce to `WEXITSTATUS'
3. Exclude WINEserver. This is a fun one. I took a look at this a while back a was able to get about 80% of it to compile native on windows. Before we can even get wineserver to build/link on mingw we still have the same problem a cygwin port has and that is what to do with the get/set thread_context stuff. Also from all I have read a mingw port would require a major redesign because of the signal/pipe usage. I looked at porting some of the stuff to windows sockets a while back and decided I still cant program well enough and I have more interesting things to do like work on ReactOS. =P
4. This may be more a mingw problem rather then something with WINE but I figured I would ask while I was making noise. When I try to build the regression tests under mingw with gcc-3.x I am getting this error. If I dont include wines libmsvcrt.a it goes away. do the exit functions in wine and mingws source not agree?
gcc registry.o testlist.o -o advapi32_test.exe -L../../../dlls -ladvapi32 -lke rnel32 -lntdll -L../../../libs/wine -lwine -L../../../libs/port -lwine_port -lm ../../../dlls/libmsvcrt.a(ds00443.o)(.text+0x0): multiple definition of `atexit' C:/mingw/bin/../lib/gcc-lib/mingw32/3.2.1/../../../crt2.o(.text+0x40):crt1.c: fi rst defined here ../../../dlls/libmsvcrt.a(ds00319.o)(.text+0x0): multiple definition of `_onexit C:/mingw/bin/../lib/gcc-lib/mingw32/3.2.1/../../../crt2.o(.text+0x60):crt1.c: fi rst defined here make[1]: *** [advapi32_test.exe] Error 1 make[1]: Leaving directory `/g/src/wine-dev/wine/dlls/advapi32/tests' make: *** [tests] Error 2
At some point I will do documentation for Mingw on MSYS/Cygwin <g> Thanks Steven
Steven Edwards Steven_Ed4153@yahoo.com writes:
- Can we set --disable-win16 CFLAGS=-DWINE_NOWINSOCK" to be default
when building under Mingw? I tried to write a configure patch for this a while back but never could get the bastard to work. Once this option is removed all we will be left with is ./configure to configure wine for mingw. None of the WINE networking stuff will really work for anyone working with mingw and I dont expect that to change anytime soon. Without this flag anything that include winsock.h or winsock2.h will puke when building on Windows. I know that WINE on linux will need win16 for a while due to older installers that are 16bit but for the mingw port thats kind of not important.
The winsock.h issues should hopefully be fixed now. I'm not sure we should disable 16-bit code by default, you will want to support that at some point.
- Can we set a conditional option to not build winegcc and winewrap?
These are not needed on Windows as they are only used to port mingw applications to winelib. Due to the use of Unixisms in these programs (fork, waitpid, etc) they wont build. Now I know we could stub fork and wrap waitpid to wait but its kind of pointless and I can see one day when someone will ask why these dont work on windows even though we build them. IMHO they just shouldnt get built for us.
I added a fix for that, hope it will work. The ultimate goal is to use winegcc etc. in the Wine build process, so it's better if they can work for you too.
- This may be more a mingw problem rather then something with WINE
but I figured I would ask while I was making noise. When I try to build the regression tests under mingw with gcc-3.x I am getting this error. If I dont include wines libmsvcrt.a it goes away. do the exit functions in wine and mingws source not agree?
It seems that mingw atexit handling is not Windows compatible. I'm not sure why they did it that way, but IMO this should be considered a mingw bug.
Alexandre Julliard wrote:
The winsock.h issues should hopefully be fixed now. I'm not sure we should disable 16-bit code by default, you will want to support that at some point. I added a fix for that, hope it will work. The ultimate goal is to use winegcc etc. in the Wine build process, so it's better if they can work for you too.
Cool, I will test your fixes tommrow.
It seems that mingw atexit handling is not Windows compatible. I'm not sure why they did it that way, but IMO this should be considered a mingw bug.
Ok I will also file a bug report with them and spam that list for a few days till someone answers <g>
Thanks Steven