Hello, I'm trying to get wine cross compiled for my distrib, a 64-bit ubuntu. I'm using: a gcc-3.4 bi-arch toolchain (gcc built with --enable-multilib); the wine-20041201 tarball; this configure command (CC is ccache gcc-3.4): AS="as --32" CC="$CC -m32" CXX="$CXX -m32" ./configure --x-libraries=/usr/X11R6/lib32 note: with AS the same as CC, it gets stuck with dlls/ntdll/relay32.s -> relay32.o these two patches : sed -i s/SYS_sigaction/SYS_rt_sigaction/g dlls/ntdll/signal_i386.c replacing ld with ld -m elf_i386 in the ld_cmd definition in tools/winebuild/main.c
With all this, I can get it to build! The problem is, it doesn't run; wine stops with this unhelpful message: wine: could not exec \uffff\uffffmU\uffff\uffffmUp/bin/wine-pthread (special characters inside)
So, I am interested in past experiences (versions used and patches): I think wine, as most applications if need be, can be built in 32-bit mode and used by amd64 distros. It would be nice if these fixes were sent back to CVS to save people headaches; I also would like to know where I can go from here, to debug the binaries I finally got.
Le mer 05/01/2005 à 17:27, Gabriel de Perthuis a écrit :
Hello, I'm trying to get wine cross compiled for my distrib, a 64-bit ubuntu. I'm using: a gcc-3.4 bi-arch toolchain (gcc built with --enable-multilib); the wine-20041201 tarball; this configure command (CC is ccache gcc-3.4): AS="as --32" CC="$CC -m32" CXX="$CXX -m32" ./configure --x-libraries=/usr/X11R6/lib32 note: with AS the same as CC, it gets stuck with dlls/ntdll/relay32.s -> relay32.o these two patches : sed -i s/SYS_sigaction/SYS_rt_sigaction/g dlls/ntdll/signal_i386.c replacing ld with ld -m elf_i386 in the ld_cmd definition in tools/winebuild/main.c
What happens with straight ./configure? By default it'll use "gcc -m32" et al, as a native x86-64 Wine is not usable yet (I don't even know if it compiles as some asm (non-portable across archs) parts are probably non-existing yet. Not to mention some other things I'm sure I'm forgetting.
With all this, I can get it to build! The problem is, it doesn't run; wine stops with this unhelpful message: wine: could not exec \uffff\uffffmU\uffff\uffffmUp/bin/wine-pthread (special characters inside)
So, I am interested in past experiences (versions used and patches): I think wine, as most applications if need be, can be built in 32-bit mode and used by amd64 distros. It would be nice if these fixes were sent back to CVS to save people headaches;
Submitting the fixes as actual patches (diff -u format) sent to wine-patches will improve the chances of the fixes get in cvs.
I also would like to know where I can go from here, to debug the binaries I finally got.
I'd first verify that they actually work on a 32-bit kernel (and 32-bit libs). Else, it's probably a build problem (so there's probably another problem lurking somewhere).
Vincent
OK, it boils down to a regression between wine-20040914 and wine-20040919: binaries won't run (wine: could not exec hUlUhUlUp/bin/wine-pthread). I suppose this problem is not new, since bleeding-edge hoary still sticks to this release.
For the record, here is how to build wine from an amd64: Use this patch (or fix include files to use signal.h from /usr/include/i386-linux): --- dlls/ntdll/signal_i386.c.orig 2005-01-06 10:41:12.000000000 +0100 +++ dlls/ntdll/signal_i386.c 2005-01-06 10:42:41.000000000 +0100 @@ -111,7 +111,7 @@ "int $0x80\n\t" "popl %%ebx" : "=a" (sig) - : "0" (SYS_sigaction), "r" (sig), "c" (new), "d" (old) ); + : "0" (SYS_rt_sigaction), "r" (sig), "c" (new), "d" (old) ); if (sig>=0) return 0; errno = -sig; return -1;
If wine is more recent than 20040919, patch Make.rules.in so that WINEBUILD is passed --ld-cmd=$(LD) (quoted properly); otherwise there is no problem.
./configure --x-libraries=/usr/X11R6/lib32 LD='ld -m elf_i386' AS will default to as --32, gcc to gcc -m32...; do not set AS to gcc -m32, though I've seen it somewhere; LD is set properly only after wine-20040919
More detail below:
Le mercredi 05 janvier 2005 à 20:45 -0500, Vincent Béron a écrit :
Le mer 05/01/2005 à 17:27, Gabriel de Perthuis a écrit :
Hello, I'm trying to get wine cross compiled for my distrib, a 64-bit ubuntu. I'm using: a gcc-3.4 bi-arch toolchain (gcc built with --enable-multilib); the wine-20041201 tarball; this configure command (CC is ccache gcc-3.4): AS="as --32" CC="$CC -m32" CXX="$CXX -m32" ./configure --x-libraries=/usr/X11R6/lib32 note: with AS the same as CC, it gets stuck with dlls/ntdll/relay32.s -> relay32.o these two patches : sed -i s/SYS_sigaction/SYS_rt_sigaction/g dlls/ntdll/signal_i386.c replacing ld with ld -m elf_i386 in the ld_cmd definition in tools/winebuild/main.c
What happens with straight ./configure? By default it'll use "gcc -m32" et al, as a native x86-64 Wine is not usable yet (I don't even know if it compiles as some asm (non-portable across archs) parts are probably non-existing yet. Not to mention some other things I'm sure I'm forgetting.
Let's see what I have changed from plain ./configure. CC='ccache gcc-3.4' is because my gcc-3.3 wasn't built with --enable-multilib; I add ccache so as to speed up make clean all, but since it could conceivably create errors maybe I'll try without.
If I don't set AS it is set to "as --32" by default, which works. I did set it explicitly because I had read somewhere that I should export AS to gcc, which failed like this: ../../tools/winebuild/winebuild -D__WINESRC__ -D_KERNEL32_ -DETCDIR=""/usr/local/etc"" -D_REENTRANT -fPIC -o relay16asm.s --relay16 gcc-3.4 -m32 -o relay16asm.o relay16asm.s /usr/lib/gcc/x86_64-linux/3.4.4/../../../../lib32/crt1.o(.text+0x18): In function `_start': ../sysdeps/i386/elf/start.S:98: undefined reference to `main' /tmp/ccJAqsbM.o(.text+0x3d): In function `__wine_call_from_16_word': : undefined reference to `wine_ldt_copy' /tmp/ccJAqsbM.o(.text+0x87): In function `__wine_call_from_16_word': : undefined reference to `RELAY_DebugCallFrom16' /tmp/ccJAqsbM.o(.text+0xa9): In function `__wine_call_from_16_word': : undefined reference to `RELAY_DebugCallFrom16Ret' /tmp/ccJAqsbM.o(.text+0x111): In function `__wine_call_from_16_long': : undefined reference to `wine_ldt_copy' /tmp/ccJAqsbM.o(.text+0x15b): In function `__wine_call_from_16_long': : undefined reference to `RELAY_DebugCallFrom16' /tmp/ccJAqsbM.o(.text+0x17d): In function `__wine_call_from_16_long': : undefined reference to `RELAY_DebugCallFrom16Ret' /tmp/ccJAqsbM.o(.text+0x1e9): In function `__wine_call_from_16_regs': : undefined reference to `wine_ldt_copy' /tmp/ccJAqsbM.o(.text+0x2e3): In function `__wine_call_from_16_regs': : undefined reference to `RELAY_DebugCallFrom16' /tmp/ccJAqsbM.o(.text+0x30a): In function `__wine_call_from_16_regs': : undefined reference to `RELAY_DebugCallFrom16Ret' /tmp/ccJAqsbM.o(.text+0x3d9): In function `__wine_call_from_16_thunk': : undefined reference to `wine_ldt_copy' /tmp/ccJAqsbM.o(.text+0x5de): In function `CALL32_CBClient': : undefined reference to `wine_ldt_copy' /tmp/ccJAqsbM.o(.text+0x66e): In function `CALL32_CBClientEx': : undefined reference to `wine_ldt_copy' collect2: ld a retourné 1 code d'état d'exécution make[2]: *** [relay16asm.o] Erreur 1 make[2]: quittant le répertoire « /home/g2p/Construction/wine/wine-20041201.orig/dlls/kernel » make[1]: *** [kernel] Erreur 2 make[1]: quittant le répertoire « /home/g2p/Construction/wine/wine-20041201.orig/dlls » make: *** [dlls] Erreur 2
A better solution is to change WINEBUILD in the makefiles to use --ld-cmd=$(LD), which involves some quoting magic.
Finally, there must be a header problem that makes SYS_sigaction be undefined (
I'd first verify that they actually work on a 32-bit kernel (and 32-bit libs). Else, it's probably a build problem (so there's probably another problem lurking somewhere).
I've just installed the binaries into a 32-bit chroot (where default wine works fine). Notice the slight difference :) : wine: could not exec hUlUhUlUp/bin/wine-pthread
Now I have my chroot, I've built wine from it and I can compare the two binaries. In its 32-bit chroot, my clean wine still crashes. So the problem with my binaries is finally amd64-unrelated. The fact that the kernel is 64-bit is unimportant since I can run the distro's i386 wine from the chroot.
gdb wine tells me that it's looking for wine in a variety of places, and simply fails to find suitable binaries. The character corruption appears only after all paths are searched.
After testing without ccache and with gcc-3.3 in the chroot, I see that the problem is with wine-20041201 and wine-20041019, whereas wine-20040914 works.
OK, it boils down to a regression between wine-20040914 and wine-20040919: binaries won't run (wine: could not exec hUlUhUlUp/bin/wine-pthread). I suppose this problem is not new, since bleeding-edge hoary still sticks to this release.
For the record, here is how to build wine from an amd64: Use this patch (or fix include files to use signal.h from /usr/include/i386-linux): --- dlls/ntdll/signal_i386.c.orig 2005-01-06 10:41:12.000000000 +0100 +++ dlls/ntdll/signal_i386.c 2005-01-06 10:42:41.000000000 +0100 @@ -111,7 +111,7 @@ "int $0x80\n\t" "popl %%ebx" : "=a" (sig) - : "0" (SYS_sigaction), "r" (sig), "c" (new), "d" (old) ); + : "0" (SYS_rt_sigaction), "r" (sig), "c" (new), "d" (old) ); if (sig>=0) return 0; errno = -sig; return -1;
If wine is more recent than 20040919, patch Make.rules.in so that WINEBUILD is passed --ld-cmd=$(LD) (quoted properly); otherwise there is no problem.
./configure --x-libraries=/usr/X11R6/lib32 LD='ld -m elf_i386' AS will default to as --32, gcc to gcc -m32...; do not set AS to gcc -m32, though I've seen it somewhere; LD is set properly only after wine-20040919
More detail below:
Le mercredi 05 janvier 2005 à 20:45 -0500, Vincent Béron a écrit :
Le mer 05/01/2005 à 17:27, Gabriel de Perthuis a écrit :
Hello, I'm trying to get wine cross compiled for my distrib, a 64-bit ubuntu. I'm using: a gcc-3.4 bi-arch toolchain (gcc built with --enable-multilib); the wine-20041201 tarball; this configure command (CC is ccache gcc-3.4): AS="as --32" CC="$CC -m32" CXX="$CXX -m32" ./configure --x-libraries=/usr/X11R6/lib32 note: with AS the same as CC, it gets stuck with dlls/ntdll/relay32.s -> relay32.o these two patches : sed -i s/SYS_sigaction/SYS_rt_sigaction/g dlls/ntdll/signal_i386.c replacing ld with ld -m elf_i386 in the ld_cmd definition in tools/winebuild/main.c
What happens with straight ./configure? By default it'll use "gcc -m32" et al, as a native x86-64 Wine is not usable yet (I don't even know if it compiles as some asm (non-portable across archs) parts are probably non-existing yet. Not to mention some other things I'm sure I'm forgetting.
Let's see what I have changed from plain ./configure. CC='ccache gcc-3.4' is because my gcc-3.3 wasn't built with --enable-multilib; I add ccache so as to speed up make clean all, but since it could conceivably create errors maybe I'll try without.
If I don't set AS it is set to "as --32" by default, which works. I did set it explicitly because I had read somewhere that I should export AS to gcc, which failed like this: ../../tools/winebuild/winebuild -D__WINESRC__ -D_KERNEL32_ -DETCDIR=""/usr/local/etc"" -D_REENTRANT -fPIC -o relay16asm.s --relay16 gcc-3.4 -m32 -o relay16asm.o relay16asm.s /usr/lib/gcc/x86_64-linux/3.4.4/../../../../lib32/crt1.o(.text+0x18): In function `_start': ../sysdeps/i386/elf/start.S:98: undefined reference to `main' /tmp/ccJAqsbM.o(.text+0x3d): In function `__wine_call_from_16_word': : undefined reference to `wine_ldt_copy' /tmp/ccJAqsbM.o(.text+0x87): In function `__wine_call_from_16_word': : undefined reference to `RELAY_DebugCallFrom16' /tmp/ccJAqsbM.o(.text+0xa9): In function `__wine_call_from_16_word': : undefined reference to `RELAY_DebugCallFrom16Ret' /tmp/ccJAqsbM.o(.text+0x111): In function `__wine_call_from_16_long': : undefined reference to `wine_ldt_copy' /tmp/ccJAqsbM.o(.text+0x15b): In function `__wine_call_from_16_long': : undefined reference to `RELAY_DebugCallFrom16' /tmp/ccJAqsbM.o(.text+0x17d): In function `__wine_call_from_16_long': : undefined reference to `RELAY_DebugCallFrom16Ret' /tmp/ccJAqsbM.o(.text+0x1e9): In function `__wine_call_from_16_regs': : undefined reference to `wine_ldt_copy' /tmp/ccJAqsbM.o(.text+0x2e3): In function `__wine_call_from_16_regs': : undefined reference to `RELAY_DebugCallFrom16' /tmp/ccJAqsbM.o(.text+0x30a): In function `__wine_call_from_16_regs': : undefined reference to `RELAY_DebugCallFrom16Ret' /tmp/ccJAqsbM.o(.text+0x3d9): In function `__wine_call_from_16_thunk': : undefined reference to `wine_ldt_copy' /tmp/ccJAqsbM.o(.text+0x5de): In function `CALL32_CBClient': : undefined reference to `wine_ldt_copy' /tmp/ccJAqsbM.o(.text+0x66e): In function `CALL32_CBClientEx': : undefined reference to `wine_ldt_copy' collect2: ld a retourné 1 code d'état d'exécution make[2]: *** [relay16asm.o] Erreur 1 make[2]: quittant le répertoire « /home/g2p/Construction/wine/wine-20041201.orig/dlls/kernel » make[1]: *** [kernel] Erreur 2 make[1]: quittant le répertoire « /home/g2p/Construction/wine/wine-20041201.orig/dlls » make: *** [dlls] Erreur 2
A better solution is to change WINEBUILD in the makefiles to use --ld-cmd=$(LD), which involves some quoting magic.
Finally, there must be a header problem that makes SYS_sigaction be undefined (
I'd first verify that they actually work on a 32-bit kernel (and 32-bit libs). Else, it's probably a build problem (so there's probably another problem lurking somewhere).
I've just installed the binaries into a 32-bit chroot (where default wine works fine). Notice the slight difference :) : wine: could not exec hUlUhUlUp/bin/wine-pthread
Now I have my chroot, I've built wine from it and I can compare the two binaries. In its 32-bit chroot, my clean wine still crashes. So the problem with my binaries is finally amd64-unrelated. The fact that the kernel is 64-bit is unimportant since I can run the distro's i386 wine from the chroot.
gdb wine tells me that it's looking for wine in a variety of places, and simply fails to find suitable binaries. The character corruption appears only after all paths are searched.
After testing without ccache and with gcc-3.3 in the chroot, I see that the problem is with wine-20041201 and wine-20041019, whereas wine-20040914 works.
OK, it boils down to a regression between wine-20040914 and wine-20040919: wine won't run, and fails with: wine: could not exec hUlUhUlUp/bin/wine-pthread I suppose this problem is not new, since bleeding-edge hoary still sticks to 20040919.
For the record, here is how to build wine from an amd64: Use this patch (or fix include files to use signal.h from /usr/include/i386-linux): --- dlls/ntdll/signal_i386.c.orig 2005-01-06 10:41:12.000000000 +0100 +++ dlls/ntdll/signal_i386.c 2005-01-06 10:42:41.000000000 +0100 @@ -111,7 +111,7 @@ "int $0x80\n\t" "popl %%ebx" : "=a" (sig) - : "0" (SYS_sigaction), "r" (sig), "c" (new), "d" (old) ); + : "0" (SYS_rt_sigaction), "r" (sig), "c" (new), "d" (old) ); if (sig>=0) return 0; errno = -sig; return -1;
If wine is more recent than 20040919, patch Make.rules.in so that WINEBUILD is passed --ld-cmd=$(LD) (quoted properly, Makefile syntax is black magic to me!); otherwise there is no problem.
./configure --x-libraries=/usr/X11R6/lib32 LD='ld -m elf_i386' AS will default to as --32, gcc to gcc -m32...; do not set AS to gcc -m32, though I've seen it somewhere; LD is set properly only after wine-20040919
More detail below:
Le mercredi 05 janvier 2005 à 20:45 -0500, Vincent Béron a écrit :
Le mer 05/01/2005 à 17:27, Gabriel de Perthuis a écrit :
Hello, I'm trying to get wine cross compiled for my distrib, a 64-bit ubuntu. I'm using: a gcc-3.4 bi-arch toolchain (gcc built with --enable-multilib); the wine-20041201 tarball; this configure command (CC is ccache gcc-3.4): AS="as --32" CC="$CC -m32" CXX="$CXX -m32" ./configure --x-libraries=/usr/X11R6/lib32 note: with AS the same as CC, it gets stuck with dlls/ntdll/relay32.s -> relay32.o these two patches : sed -i s/SYS_sigaction/SYS_rt_sigaction/g dlls/ntdll/signal_i386.c replacing ld with ld -m elf_i386 in the ld_cmd definition in tools/winebuild/main.c
What happens with straight ./configure? By default it'll use "gcc -m32" et al, as a native x86-64 Wine is not usable yet (I don't even know if it compiles as some asm (non-portable across archs) parts are probably non-existing yet. Not to mention some other things I'm sure I'm forgetting.
Let's see what I have changed from plain ./configure. CC='ccache gcc-3.4' is because my gcc-3.3 wasn't built with --enable-multilib; I add ccache so as to speed up make clean all, but since it could conceivably create errors maybe I'll try without.
If I don't set AS it is set to "as --32" by default, which works. I did set it explicitly because I had read somewhere that I should export AS to gcc, which failed like this: ../../tools/winebuild/winebuild -D__WINESRC__ -D_KERNEL32_ -DETCDIR=""/usr/local/etc"" -D_REENTRANT -fPIC -o relay16asm.s --relay16 gcc-3.4 -m32 -o relay16asm.o relay16asm.s /usr/lib/gcc/x86_64-linux/3.4.4/../../../../lib32/crt1.o(.text+0x18): In function `_start': ../sysdeps/i386/elf/start.S:98: undefined reference to `main' /tmp/ccJAqsbM.o(.text+0x3d): In function `__wine_call_from_16_word': : undefined reference to `wine_ldt_copy' /tmp/ccJAqsbM.o(.text+0x87): In function `__wine_call_from_16_word': : undefined reference to `RELAY_DebugCallFrom16' /tmp/ccJAqsbM.o(.text+0xa9): In function `__wine_call_from_16_word': : undefined reference to `RELAY_DebugCallFrom16Ret' /tmp/ccJAqsbM.o(.text+0x111): In function `__wine_call_from_16_long': : undefined reference to `wine_ldt_copy' /tmp/ccJAqsbM.o(.text+0x15b): In function `__wine_call_from_16_long': : undefined reference to `RELAY_DebugCallFrom16' /tmp/ccJAqsbM.o(.text+0x17d): In function `__wine_call_from_16_long': : undefined reference to `RELAY_DebugCallFrom16Ret' /tmp/ccJAqsbM.o(.text+0x1e9): In function `__wine_call_from_16_regs': : undefined reference to `wine_ldt_copy' /tmp/ccJAqsbM.o(.text+0x2e3): In function `__wine_call_from_16_regs': : undefined reference to `RELAY_DebugCallFrom16' /tmp/ccJAqsbM.o(.text+0x30a): In function `__wine_call_from_16_regs': : undefined reference to `RELAY_DebugCallFrom16Ret' /tmp/ccJAqsbM.o(.text+0x3d9): In function `__wine_call_from_16_thunk': : undefined reference to `wine_ldt_copy' /tmp/ccJAqsbM.o(.text+0x5de): In function `CALL32_CBClient': : undefined reference to `wine_ldt_copy' /tmp/ccJAqsbM.o(.text+0x66e): In function `CALL32_CBClientEx': : undefined reference to `wine_ldt_copy' collect2: ld a retourné 1 code d'état d'exécution make[2]: *** [relay16asm.o] Erreur 1 make[2]: quittant le répertoire « /home/g2p/Construction/wine/wine-20041201.orig/dlls/kernel » make[1]: *** [kernel] Erreur 2 make[1]: quittant le répertoire « /home/g2p/Construction/wine/wine-20041201.orig/dlls » make: *** [dlls] Erreur 2
A better solution is to change WINEBUILD in the makefiles to use --ld-cmd=$(LD), which involves some quoting magic.
Finally, there must be a header problem that makes SYS_sigaction be undefined.
I'd first verify that they actually work on a 32-bit kernel (and 32-bit libs). Else, it's probably a build problem (so there's probably another problem lurking somewhere).
I've just installed the binaries into a 32-bit chroot (where default wine works fine). Notice the slight difference :) : wine: could not exec hUlUhUlUp/bin/wine-pthread
Now I have my chroot, I've built wine from it and I can compare the two binaries. In its 32-bit chroot, my clean wine still crashes. So the problem with my binaries is finally amd64-unrelated. The fact that the kernel is 64-bit is unimportant since I can run the distro's i386 wine from the chroot.
gdb wine tells me that it's looking for wine in a variety of places, and simply fails to find suitable binaries. The character corruption appears only after all paths are searched.
After testing without ccache and with gcc-3.3 in the chroot, I see that the problem is with wine-20041201 and wine-20041019, whereas wine-20040914 works.
-
Gabriel de Perthuis -
Vincent Béron