Hi,
I've tried to get wine to compile under a 2.2.17 kernel machine (w/ RedHat 7.0), not particularly because of Stefan's problems under RH-5.2, but trying to track down some other bugs (although hopefully the patches will help a little :)
The first stumbling block was in dlls/ntdll/cdrom.c. Two routines in the file try to set members of the cdrom_generic_command structure (defined in linux/cdrom.h) that don't exist in 2.2.x kernels, but do exist in 2.4.x kernels.
The attached patch adds configure checks for these structure members and puts "#ifdef"s around the assignments in dlls/ntdll/cdrom.c . I don't know the knock-on effects for not setting these values, but presumably getting something to work is better than wine not compiling :)
On a point of style, should there be one test for these two structure members, or two independent tests? The members appear in the kernel at the same time (2.2.x -> 2.4.0)
ChangeLog: Towards fixing compilation under 2.2.x kernels
NB both configure and include/config.h.in need to be regenerated.
... but, the problems didn't stop there. The compilation continues until it starts to use wmc, which core-dumps on the /second/ usage.
------------------------[ Compilation log ]--------------------------- [...] make[2]: Leaving directory `/scratch/remus1/paulm/wine/dlls/ntdll' rm -f ntdll.dll.so && ln -s ntdll/ntdll.dll.so ntdll.dll.so rm -f libntdll.dll.so && ln -s ntdll/ntdll.dll.so libntdll.dll.so make[2]: Entering directory `/scratch/remus1/paulm/wine/dlls/kernel' LD_LIBRARY_PATH="../../library:../../unicode:$LD_LIBRARY_PATH" ../../tools/wmc/wmc -i -H /dev/null -o messages/winerr_enu.mc.rc messages/winerr_enu.mc DEBUG: setting up handler DEBUG: getting time DEBUG: cmdlen=72 LD_LIBRARY_PATH="../../library:../../unicode:$LD_LIBRARY_PATH" ../../tools/wrc/wrc -I. -I. -I../../include -I../../include -o kernel.res -r kernel.rc make[2]: *** [kernel.res] Segmentation fault (core dumped) make[2]: Leaving directory `/scratch/remus1/paulm/wine/dlls/kernel' make[1]: *** [kernel/kernel32.dll.so] Error 2 make[1]: Leaving directory `/scratch/remus1/paulm/wine/dlls' make: *** [dlls] Error 2 [paulm@mowgli wine]$ ------------------------------[ End of log ]-------------------------
The DEBUG output above was from the following patch:
--- wmc.c 10 Mar 2002 00:24:24 -0000 1.3 +++ wmc.c 11 May 2002 19:49:33 -0000 @@ -125,8 +125,10 @@ int i; int cmdlen;
+ printf( "DEBUG: setting up handler\n"); signal(SIGSEGV, segvhandler);
+ printf( "DEBUG: getting time\n"); now = time(NULL);
/* First rebuild the commandline to put in destination */ @@ -134,6 +136,7 @@ cmdlen = 4; /* for "wmc " */ for(i = 1; i < argc; i++) cmdlen += strlen(argv[i]) + 1; + printf( "DEBUG: cmdlen=%u\n", cmdlen); cmdline = (char *)xmalloc(cmdlen); strcpy(cmdline, "wmc "); for(i = 1; i < argc; i++)
so, wmc is crashing before it is running main(), suggesting some linking problem? The machine is running glibc 2.2.4 (via RedHat RPM glibc-2.2.4-18.7.0.3) and I was compiling with the alleged "v2.96" release of gcc (RPM gcc-2.96-85).
Any ideas?
Cheers,
---- Paul Millar
On Sun, 12 May 2002, Paul Millar wrote: [...]
The first stumbling block was in dlls/ntdll/cdrom.c. Two routines in the file try to set members of the cdrom_generic_command structure (defined in linux/cdrom.h) that don't exist in 2.2.x kernels, but do exist in 2.4.x kernels.
See also the patch I sent there: http://www.winehq.com/hypermail/wine-devel/2002/05/0244.html
Note that you don't need to set cmd.quiet to 0 since you did a memset just before. So you only need the configure check for the timeout field.
The attached patch adds configure checks for these structure members and puts "#ifdef"s around the assignments in dlls/ntdll/cdrom.c . I don't know the knock-on effects for not setting these values, but presumably getting something to work is better than wine not compiling :)
I don't know. It could be seen as sweeping the bug under the carpet. Also it will probably make it quite hard to find out what's wrong.
-- Francois Gouget fgouget@free.fr http://fgouget.free.fr/ Computers are like airconditioners They stop working properly if you open WINDOWS
On Sun, 12 May 2002, Francois Gouget wrote:
See also the patch I sent there: http://www.winehq.com/hypermail/wine-devel/2002/05/0244.html
Sorry Francois, I had read your email but missed the bottom half of your patch. I've altered the patch so it just augments yours. Now it just adds the configure test for the timeout member, defining HAVE_CDROM_TIMEOUT if it exists.
ChangeLog: Add test to check if cdrom_generic_command has the timeout member.
NB configure and include/config.h.in must be regenerated after this patch.
Note that you don't need to set cmd.quiet to 0 since you did a memset just before. So you only need the configure check for the timeout field.
True, but I was anticipating that this might be set to some other value in the future. Having the test would illustrate the potential problem, but I think you're right to get ride of the assignment.
I don't know the knock-on effects for not setting these values, but presumably getting something to work is better than wine not compiling :)
I don't know. It could be seen as sweeping the bug under the carpet. Also it will probably make it quite hard to find out what's wrong.
I think the bug is lack of support in earlier kernels, which we have limited control over. We could issue a warning during the configure stage that there might be problems with CDROM drives, but if wine uses features only present in recent kernels, then there will always be this "sweeping bugs under the carpet" problem ... e.g. kernel-2.[56] support for EA and hidden files.
---- Paul Millar
Paul Millar paulm@astro.gla.ac.uk writes:
I think the bug is lack of support in earlier kernels, which we have limited control over. We could issue a warning during the configure stage that there might be problems with CDROM drives, but if wine uses features only present in recent kernels, then there will always be this "sweeping bugs under the carpet" problem ... e.g. kernel-2.[56] support for EA and hidden files.
Note that the layout of the structure at compile-time has nothing to do with the features that the kernel supports at run-time. And the usual way to fix this kind of problem is to simply redefine the necessary structure ourselves; this way it works with all kernels even if you don't have the proper headers on the build machine.
-
Alexandre Julliard -
Francois Gouget -
Paul Millar