On Tue, May 10, 2011 at 20:19, Frederic Weisbecker <fweis...@gmail.com> wrote: > On Tue, May 10, 2011 at 07:43:37PM -0500, Austin English wrote: >> On Tue, May 10, 2011 at 19:41, Frederic Weisbecker <fweis...@gmail.com> >> wrote: >> > It seems not adapted to 64 bits in fact. >> > The part that complains is in an "#ifdef __i386__", and there >> > is an alternate __x86_64__ section. It seems the section that has been >> > compiled is the i386 even if I'm running amd64, which may be the >> > cause of the issue. >> > >> > So the problem appears to be more in the test implementation of wine. >> >> Unless you configured wine with --enable-win64 when building, wine is >> being compiled as a 32-bit application. >> >> Though I'm more worried about the i386 case failing :). > > There are few chances that 2.6.32 is concerned by a trap/breakpoints > bug that such a test could detect. The trap/breakpoints bugs have started > in 2.6.33 when we wrote the breakpoint subsystem, which caused some > regressions. > If a problem was there before, and it's detected by a wine test, I think it > would > have been reported a while ago already.
In 2.6.32 the test simply hangs indefinitely. The testcase was added to wine after 2.6.33 came out and broke WoW :). > So I think it's likely a problem in the wine selftest. I just can't find > my way in that code. The address of test_stage is supposed to match some > address given as argument to the test. But test_stage addr has not been > read before that happens, and it's a static var. How could it match anything. > Anyway, I'm definetly clueless there :) Alexandre? -- -Austin -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
