Hi,
I've managed to compile the current CVS version under AMD64, according to the WineOn64bit-Wiki for Debian. So far, so good.
However, all tests fail and starting wine gives an error code of 2. --version gives no output. wine-kthread gives an error code of 139 (segmentation violation), wine-pthread seems to work. Debugging wine shows that the error appears when execve'ing (should have been somewhat obvious ;-)
When debugging wine-kthread, I get the following error on the first line of code: 0x557721ba in __libc_pthread_init () from /emul/ia32-linux/lib/tls/libc.so.6
Interestingly, my libc.so.6 link points to libc-2.3.2.so. Hope that is ok... it is defined in the ia32-libc6 debian package from stable. :->
Might this have something to do with my 4GB of memory? I am open for suggestions...
Best, Alex
On latest Debian (or at least Ubuntu), you have to force compile without the stack protector on by doing -fno-stack-protector.
See this bug: http://bugs.winehq.org/show_bug.cgi?id=6035
That said, I don't actually know if that's the issue you're running into.
Thanks, Scott Ritchie
On Mon, 2006-10-02 at 23:07 +0200, Alexander K. Seewald wrote:
Hi,
I've managed to compile the current CVS version under AMD64, according to the WineOn64bit-Wiki for Debian. So far, so good.
However, all tests fail and starting wine gives an error code of 2. --version gives no output. wine-kthread gives an error code of 139 (segmentation violation), wine-pthread seems to work. Debugging wine shows that the error appears when execve'ing (should have been somewhat obvious ;-)
When debugging wine-kthread, I get the following error on the first line of code: 0x557721ba in __libc_pthread_init () from /emul/ia32-linux/lib/tls/libc.so.6
Interestingly, my libc.so.6 link points to libc-2.3.2.so. Hope that is ok... it is defined in the ia32-libc6 debian package from stable. :->
Might this have something to do with my 4GB of memory? I am open for suggestions...
Best, Alex
On Mon, Oct 02, 2006 at 03:05:25PM -0700, Scott Ritchie wrote:
On latest Debian (or at least Ubuntu), you have to force compile without the stack protector on by doing -fno-stack-protector.
Thanks for the tip.
* I compiled with gcc-4.0 (GCC) 4.0.3 20051201 (prerelease) (Debian 4.0.2-5), which does not have the stack-protector options. But it might still insert similar code... * I updated to gcc-4.1 (GCC) 4.1.2 20060901 (prerelease) (Debian 4.1.1-13), and binutils 2.17-2 from Debian testing. In the process, I got all kinds of errors, so I updated from CVS. However, it currently seems broken, as configure says: config.status: error: cannot find input file: dlls/resutils/Makefile.in
So I switched back to wine-0.9.22 from sourceforge.net...
First I get the error: In file included from ../../include/windef.h:234, from ../../include/wine/library.h:27, from ./config.c:36: ../../include/winnt.h:881: error: conflicting types for 'CONTEXT' ../../include/winnt.h:722: error: previous declaration of 'CONTEXT' was here
When I change the #ifdef in windef.h to something other than __x86_64_ (was mentioned in one HowTo), it runs a bit longer, but then I get the error:
{standard input}: Assembler messages: {standard input}:1586: Error: suffix or operands invalid for `push' {standard input}:1589: Error: suffix or operands invalid for `pop' {standard input}:2532: Error: suffix or operands invalid for `push' {standard input}:2533: Error: suffix or operands invalid for `mov' {standard input}:2535: Error: suffix or operands invalid for `pop' {standard input}:2780: Error: suffix or operands invalid for `push' {standard input}:2781: Error: suffix or operands invalid for `mov' {standard input}:2783: Error: suffix or operands invalid for `pop'
.. which indicates that some assembly code is not compatible with the latest binutils. Compilation with gcc-4.0 works without problems, except of course that the binary does not work (see my last EMail).
Just compiling the whole loader subdir with -fno-stack-protector and gcc-4.1 runs successfully. Now ./wine-kthread and ./wine-pthread both work, while ./wine-preloader exits with code 2. ./wine still exits with the same error code. Seems to be a small step forward. ;-)
I'll keep trying to compile all of it under gcc-4.1. The most likely explanation is that the stack protector code introduces similar problems elsewhere, so compiling all under gcc-4.1 _may_ solve this.
Best, Alex
On Mon, Oct 02, 2006 at 03:05:25PM -0700, Scott Ritchie wrote:
On latest Debian (or at least Ubuntu), you have to force compile without the stack protector on by doing -fno-stack-protector.
See this bug: http://bugs.winehq.org/show_bug.cgi?id=6035
That said, I don't actually know if that's the issue you're running into.
I've verified that this does not solve the problem by recompiling wine with gcc-4.1 -fno-stack-protector. Still having basically the same problem.
I've traced the problem to line 429 in libs/wine/config.c, execv( full_name, new_argv ). In this call, the program exists with return code 2. What could conceivably make this call return 2 without any error messages?
wine-pthread --version and wine-kthread --version works, wineserver seems to work; ./wine-preloader gives same error code 2 (csh, $?) as wine; debugging it does not help as it is a library. I get the following message, though:
warning: Lowest section in system-supplied DSO at 0xffffe000 is .hash at ffffe094
I get a lot of... build_new_path (path=Cannot access memory at address 0xffffd748) at glibc.c:80 .. during gdb wine. Perhaps my kernel has problems running 32bit code? The addresses seem to indicate that 32bit code might overrun on these memory addresses, which could explain segfault etc..
Is there a way to get better error output so I can find out what is wrong? I'm considering putting fprintf(stderr, ..) statements into the code which surely is a bad sign. ;-)
Best, Alex
-
Alexander K. Seewald -
Scott Ritchie