Hi! I would like to ask for a help with wine compilation on an x86_64 system. Today I successfully did the compilation, but the result is totally unusable. I've supplied -m32 switch to both CFLAGS and LDFLAGS (I have to specify my own C/LDFLAGS because of custom -I/-L options to find various packages). gcc as well as winegcc correctly generated 32bit output. There was just one error during compilation - it attempted to compile dlls/ntdll/signal_i386.c, which suffered from __NR_sigaction being undefined. Because my kernel headers are set up for a 64bit system, there is not such a define. __NR_rt_sigaction is defined instead. I'm not sure whether it's ok that wine tried to compile this file (it compiled signal_x86_64.c too, with no problems). I also don't know how to hack the kernel includes to define it correctly (I have just vanilla, unmodified set of native kernel headers for 2.6.17-rc5 set up). So I hacked it by copying the appropriate #define from asm-i386/unistd.h kernel header directly to signal_i386.c. wine then compiled and installed without a glitch. However, any attempt to run it ends up with immediate return without any diagnosis. It even doesn't output its usage help. I've already compiled a lot of "normal" programs for 32bit systems on my x86_64 system. However, wine resists. What am I doing wrong ? What's the correct way ? With regards, Pavel Trolle
Pavel Troller wrote:
I would like to ask for a help with wine compilation on an x86_64 system.
http://wiki.winehq.org/WineOn64bit
bye michael
Today I successfully did the compilation, but the result is totally unusable. I've supplied -m32 switch to both CFLAGS and LDFLAGS (I have to specify my own C/LDFLAGS because of custom -I/-L options to find various packages). gcc as well as winegcc correctly generated 32bit output. There was just one error during compilation - it attempted to compile dlls/ntdll/signal_i386.c, which suffered from __NR_sigaction being undefined. Because my kernel headers are set up for a 64bit system, there is not such a define. __NR_rt_sigaction is defined instead. I'm not sure whether it's ok that wine tried to compile this file (it compiled signal_x86_64.c too, with no problems). I also don't know how to hack the kernel includes to define it correctly (I have just vanilla, unmodified set of native kernel headers for 2.6.17-rc5 set up). So I hacked it by copying the appropriate #define from asm-i386/unistd.h kernel header directly to signal_i386.c. wine then compiled and installed without a glitch. However, any attempt to run it ends up with immediate return without any diagnosis. It even doesn't output its usage help. I've already compiled a lot of "normal" programs for 32bit systems on my x86_64 system. However, wine resists. What am I doing wrong ? What's the correct way ? With regards, Pavel Trolle
Hi Pavel,
One thing to consider is where gcc finds your X libraries. Wine knows its on a x86_64 system and supplies the -m32 itself. Of course, you will have to watch out for missing required packages reported by configure (bison, flex libxml2-devel, libxslt-devel, cups-devel, fontforge, freetype2-devel-32bit, zlib-devel-32bit, xorg-x11-devel-32bit, mesa-devel-32bit, hal-devel are the packages I had to add on my SUSE 10.1 system). All I then have to type to build wine is
./configure --x-libraries=/usr/X11R6/lib && make depend && make
then
make install (as root).
-- Andy.
Pavel Troller wrote:
Hi! I would like to ask for a help with wine compilation on an x86_64 system. Today I successfully did the compilation, but the result is totally unusable. I've supplied -m32 switch to both CFLAGS and LDFLAGS (I have to specify my own C/LDFLAGS because of custom -I/-L options to find various packages). gcc as well as winegcc correctly generated 32bit output. There was just one error during compilation - it attempted to compile dlls/ntdll/signal_i386.c, which suffered from __NR_sigaction being undefined. Because my kernel headers are set up for a 64bit system, there is not such a define. __NR_rt_sigaction is defined instead. I'm not sure whether it's ok that wine tried to compile this file (it compiled signal_x86_64.c too, with no problems). I also don't know how to hack the kernel includes to define it correctly (I have just vanilla, unmodified set of native kernel headers for 2.6.17-rc5 set up). So I hacked it by copying the appropriate #define from asm-i386/unistd.h kernel header directly to signal_i386.c. wine then compiled and installed without a glitch. However, any attempt to run it ends up with immediate return without any diagnosis. It even doesn't output its usage help. I've already compiled a lot of "normal" programs for 32bit systems on my x86_64 system. However, wine resists. What am I doing wrong ? What's the correct way ?
There are quite a few places that use i386 syscalls directly and you just fixed the one place it was detected. What you need to do is to copy a 32-bit unistd.h to asm-i386/unistd.h and make sure that it is included correctly by asm/unistd.h.
Hi Rob!
There are quite a few places that use i386 syscalls directly and you just fixed the one place it was detected. What you need to do is to copy a 32-bit unistd.h to asm-i386/unistd.h and make sure that it is included correctly by asm/unistd.h.
Many thanks for your explanation. So I created my own /usr/include/asm directory and wrote a small script, which populated it with files like this sample:
/* Automatically generated wrapper for asm/unistd.h - do not edit */
#ifdef __i386__ # include <asm-i386/unistd.h> #else # ifdef __x86_64__ # include <asm-x86_64/unistd.h> # else # error "Unknown architecture, neither i386 nor x86_64" # endif #endif
asm-i386 and asm-x86_64 contain the appropriate headers from the kernel tree. I hope it's a good solution to have a flexible bi-arch development system.
After that, I recompiled wine (and removed my previous unistd.h hack first). The resulting wine is fully functional now. With regards, Pavel Troller
-
Andrew Talbot -
Michael Stefaniuc -
Pavel Troller -
Robert Shearman