Compiling wine on an x86-64 system

[Pavel Troller]

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

[Michael Stefaniuc]

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

-- 
Michael Stefaniuc               Tel.: [phone]
Sr. Network Engineer            Fax.: [phone]
Red Hat GmbH                    Email: mstefani(a)redhat.com
Hauptstaetterstr. 58            http://www.redhat.de/
D-70178 Stuttgart

[Andrew Talbot]

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.

[Robert Shearman]

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.

-- 
Rob Shearman

[Pavel Troller]

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