I've done a lot of reading on this problem and don't understand why what I have
doesn't work.
I have an entirely 32 bit jail, created by cross-compiling the world with
TARGET=i386 and creating a jail from DESTDIR.
The jail appears to be fully functional - all programs appear to work and
the compiler produces i386 binaries.
'uname' has been configured to identify itself as 'i386', so even compiling
programs from source works (autoconf correctly recognises the jail system
as i386, etc).
However, installing the wine port and attempting to do anything with it
results in:
$ wine hello.exe
Bus error: 10 (core dumped)
The program will immediately crash in all cases.
$ winecfg
Bus error: 10 (core dumped)
According to every bit of documentation I can find online, this should
work fine. Any idea what's gone wrong here?
xw
_______________________________________________
freebsd...@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hacke...@freebsd.org"
Wine is an exceptional bit of software, in many ways.
One way it is exceptional is that it uses the system in a number of
ways that nothing else does. For example it sets various special
segment register settings and defines several different
segments on the LDT. This is something that is different to some
extent between i386 and amd64 and it is possible that
the code for 386 LDT syscalls under amd64 may not work correctly.
nothing else would test this.
I agree and would also have likely not even tried if it wasn't for
reading on FreeBSD's own wiki (amonst other places) that it should
actually work fine. I've tried various versions and always get the
same result:
"FreeBSD currently lacks support for 32bit ports on a 64bit system.
However, with a little bit of effort you can build and use the 32 bit
wine executable on an amd64 system (Diablo 2 works just fine)."
His instructions show an essentially identical setup to mine (apart
from the fact that he's running a chroot and I'm running a jail).
Even any ideas on how to debug this would help.
I'm using 7.2-RELEASE-p4 here.
Ah, thanks.
I assume they won't have made it into 8.0-RELEASE when it shows up?
You forgot to note the version of the kernel you use.
Required syscalls only implemented in 8/HEAD.
It is in 8.0.
jail may not alow you to do the LDT system calls.
have you tried a chroot?
I would like to help get this working.. is there a howto somewhere to
setup a i386 jail on amd64?
I used teh instructions on http://wiki.freebsd.org/Wine (and pointed
the jail to /compat/i386)
Inside teh jail uname -a still produces this:
FreeBSD i386.puffybsd.com 8.0-RC3 FreeBSD 8.0-RC3 #0: Wed Nov 18
22:22:44 UTC 2009 root@:/usr/obj/usr/src/sys/WORKSTATION amd64
so trying to compile mesa-demos produces this
/../../src/mesa/x86-64/glapi_x86-64.S:29003: Error: suffix or operands
invalid for `pop'
./../../src/mesa/x86-64/glapi_x86-64.S:29004: Error: suffix or
operands invalid for `pop'
./../../src/mesa/x86-64/glapi_x86-64.S:29005: Error: `6128(%rax)' is
not a valid 32 bit base/index expression
./../../src/mesa/x86-64/glapi_x86-64.S:29006: Error: bad register name `%r11'
./../../src/mesa/x86-64/glapi_x86-64.S:29040: Error: suffix or
operands invalid for `push'
./../../src/mesa/x86-64/glapi_x86-64.S:29041: Error: suffix or
operands invalid for `push'
./../../src/mesa/x86-64/glapi_x86-64.S:29042: Error: suffix or
operands invalid for `push'
./../../src/mesa/x86-64/glapi_x86-64.S:29043: Error: suffix or
operands invalid for `push'
./../../src/mesa/x86-64/glapi_x86-64.S:29044: Error: suffix or
operands invalid for `push'
./../../src/mesa/x86-64/glapi_x86-64.S:29046: Error: suffix or
operands invalid for `pop'
./../../src/mesa/x86-64/glapi_x86-64.S:29047: Error: suffix or
operands invalid for `pop'
./../../src/mesa/x86-64/glapi_x86-64.S:29048: Error: suffix or
operands invalid for `pop'
./../../src/mesa/x86-64/glapi_x86-64.S:29049: Error: suffix or
operands invalid for `pop'
./../../src/mesa/x86-64/glapi_x86-64.S:29050: Error: suffix or
operands invalid for `pop'
./../../src/mesa/x86-64/glapi_x86-64.S:29051: Error: `6136(%rax)' is
not a valid 32 bit base/index expression
./../../src/mesa/x86-64/glapi_x86-64.S:29052: Error: bad register name `%r11'
./../../src/mesa/x86-64/glapi_x86-64.S:29086: Error: suffix or
operands invalid for `push'
./../../src/mesa/x86-64/glapi_x86-64.S:29087: Error: suffix or
operands invalid for `push'
./../../src/mesa/x86-64/glapi_x86-64.S:29088: Error: suffix or
operands invalid for `push'
./../../src/mesa/x86-64/glapi_x86-64.S:29090: Error: suffix or
operands invalid for `pop'
./../../src/mesa/x86-64/glapi_x86-64.S:29091: Error: suffix or
operands invalid for `pop'
./../../src/mesa/x86-64/glapi_x86-64.S:29092: Error: suffix or
operands invalid for `pop'
./../../src/mesa/x86-64/glapi_x86-64.S:29093: Error: `6144(%rax)' is
not a valid 32 bit base/index expression
./../../src/mesa/x86-64/glapi_x86-64.S:29094: Error: bad register name `%r11'
./../../src/mesa/x86-64/glapi_x86-64.S:29124: Error: suffix or
operands invalid for `push'
./../../src/mesa/x86-64/glapi_x86-64.S:29125: Error: suffix or
operands invalid for `push'
./../../src/mesa/x86-64/glapi_x86-64.S:29126: Error: suffix or
operands invalid for `push'
./../../src/mesa/x86-64/glapi_x86-64.S:29128: Error: suffix or
operands invalid for `pop'
./../../src/mesa/x86-64/glapi_x86-64.S:29129: Error: suffix or
operands invalid for `pop'
./../../src/mesa/x86-64/glapi_x86-64.S:29130: Error: suffix or
operands invalid for `pop'
./../../src/mesa/x86-64/glapi_x86-64.S:29131: Error: `6152(%rax)' is
not a valid 32 bit base/index expression
./../../src/mesa/x86-64/glapi_x86-64.S:29132: Error: bad register name `%r11'
gmake[2]: *** [../../../src/mesa/x86-64/glapi_x86-64.o] Error 1
gmake[2]: Leaving directory
`/usr/ports/graphics/mesa-demos/work/Mesa-7.4.4/src/glx/x11'
gmake[1]: *** [subdirs] Error 1
gmake[1]: Leaving directory `/usr/ports/graphics/mesa-demos/work/Mesa-7.4.4/src'
gmake: *** [default] Error 1
*** Error code 1
Sam Fourman Jr.
Hello.
Not sure about the mesa problem at the moment, but I made uname identify
itself as i386 by just setting UNAME_m=i386 in the environment.
You could put this in the shell environment of the user you run as inside
the jail.
xw
good luck.
ps.: Do I waste time sending replies that maybe will not help anybody, with idiot thoughs like: "hey guys, what about we taylor an prototype of an a.i. managed not human operating system, that is not so simple to be handled by any simple person except for a few seconds at every century by prodigy minds more exceptional than any existing mythological wisdom, and without any crt and hack objects or strange acpi boring dependencies that nobody want to explain, just to perform the simple task of running other two kernels, like a freebsd code at cpu0 and a slackware code at cpu1, and have triple-eyed super-kernel force balancing shared jobs of an world wide clustered extensible system?"
nevermind.
> Date: Fri, 20 Nov 2009 03:29:56 +0000
> From: xorqu...@googlemail.com
> To: sfou...@gmail.com
> CC: freebsd...@freebsd.org
> Subject: Re: Wine on amd64 in 32 bit jail
_________________________________________________________________
Novo windowslive.com.br. Descubra como juntar a galera com os produtos Windows Live.
http://www.windowslive.com.br/?ocid=WindowsLive09_MSN_Hotmail_Tagline_out09_______________________________________________
Didn't your mother tell you to not eat other people's medications?
:-)
Julian
Underdog - planning to write a book now
> Date: Fri, 20 Nov 2009 10:43:17 -0800
> From: jul...@elischer.org
> To: gatinhodos...@hotmail.com
> CC: freebsd...@freebsd.org
> Subject: Re: Wine on amd64 in 32 bit jail - for stupid peaple only
_________________________________________________________________
Agora a pressa � amiga da perfei��o. Chegou o Windows 7. Conhe�a!
http://www.microsoft.com/brasil/windows7/default.html?WT.mc_id=1539_______________________________________________
>>> Wine is an exceptional bit of software, in many ways.
>> http://wiki.freebsd.org/Wine
>>
>> "FreeBSD currently lacks support for 32bit ports on a 64bit system.
>> However, with a little bit of effort you can build and use the 32 bit
>> wine executable on an amd64 system (Diablo 2 works just fine)."
>>
>> His instructions show an essentially identical setup to mine (apart
>> from the fact that he's running a chroot and I'm running a jail).
>
> jail may not alow you to do the LDT system calls.
>
> have you tried a chroot?
Is there any reason to fear Microsoft viruses infecting Wine programs? Is
that why he is using a jail? Would there be a greater danger of virus
infection with chroot?
>
>>
>> Even any ideas on how to debug this would help.
>>
>> xw
>
> _______________________________________________
> freebsd...@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
> To unsubscribe, send any mail to "freebsd-hacke...@freebsd.org"
>
*----------------------------------------------------------*
Kayven Riese, BSCS, MS (Physiology and Biophysics)
(415) 902 5513 cellular
http://kayve.net
Webmaster http://ChessYoga.org
*----------------------------------------------------------*
>
> neither I believe I was sober, bleh :P
>
>
>
> Underdog - planning to write a book now
S00per! {:D what's it gonna be called?
*----------------------------------------------------------*
I was thinking just as a test, but others have answered the question I
believe.
In principle, yes, because Wine is supposed to be a complete
reimplementation of the win32 API, thus any program that runs
differently on Wine than on Windows demonstrates a bug in Wine.
(IIRC there are a few Windows viruses that do run on wine.)
In practice, any Wine bug that impairs only viruses will probably
not be a high priority to get fixed :)
I haven't tried wine, but I do have an i386 jail on my main amd64
server (primarily to build apps for my netbook) and have managed to
build all the apps I want (including Firefox, OpenOffice.org and
jdk15). I have a full i386 world installed in the jail and have
the following overrides in my environment:
MACHINE=i386
UNAME_p=i386
UNAME_m=i386
I did run into problems initially because my i386 userland wasn't
aligned with my amd64 kernel but rebuilding both fixed that (I'm
running 8.0-RC1 and a bit).
Note that some tools that poke around in kernel innards won't work -
ps and lsof are the most obvious. ktrace works but the resultant
ktrace.out files need to read with an amd64 kdump.
>Inside teh jail uname -a still produces this:
>FreeBSD i386.puffybsd.com 8.0-RC3 FreeBSD 8.0-RC3 #0: Wed Nov 18
>22:22:44 UTC 2009 root@:/usr/obj/usr/src/sys/WORKSTATION amd64
You are missing the UNAME_x environment variables.
>so trying to compile mesa-demos produces this
It will compile and run with the above environment changes.
--
Peter Jeremy
Some of those issues can be solved by using within 32-bit jail
statically linked 64-bit binaries. It does work for ps which is
available in /rescue .
--Artem
A word of caution: not all the ioctl's and setsockopt's have the
proper glue code under COMBAT_FREEBSD32. For example, running ifconfig
on 7.2 i386-on-amd64 is unable to set an ip address, and syscons
ioctls are completely broken. The program will build properly, but
will be unreliable at runtime (seemingly out of the blue segfaults, a
few cases of sigbus). Especially if they do a blind cast without
sanity checking and confinue forward on error.
While this may not seem that relevant on a build machine, remember
that autoconf generates tiny stub binaries and runs them to determine
'compatibility' for the binary it intends to build. It may feed
information that will lead it to making incorrect guesses about the
target environment. It's not very common, but it has happened, and can
fly under the radar.