Wine, Windows.Forms on Linux, GC and segfaults.
marcus at jet.franken.de
Mon Dec 16 08:09:19 CST 2002
On Wed, Dec 11, 2002 at 01:05:32PM -0500, Miguel de Icaza wrote:
> > > The problem is that by the time that Wine has been initialized,
> > > using setjmp/longjmp will always lead to a crash. The code
> > > in pthreads
> > > that performs the longjmp will first try to invoke the pthread cleanup
> > > routines, and then invoke longjmp. This never happens.
> > You can't and needn't link with -lpthread. Wine has its own
> > pthread implmentation.
> > I tried your included code and it works just fine unless you
> > link with -lpthread, then it crashes in the same way as in your
> > attached picture. But then you should never link Wine with
> > -lpthread so that is not really a bug.
> > Of course Wine pthread implementation it not in any way complete
> > so some function might be missing and some might only be only
> > partially implemented and of course some might be incorrectly
> > implemented.
> > So please try again without linking with -lpthread.
> The problem is that this is very hard for us to do as two of the
> underlying libraries we are using (libmono and libgc) both link against
> pthread to achieve their threading capabilities.
> It might be better to investigate what are Wine's requirements for
> having its own pthread implementation, and have those changed pushed to
> the maintainers of pthreads.
> In particular, we are interested in using WineLib, maybe it would be
> possible to have WineLib use the standard pthread implementation instead
> of rolling its own?
This would be very difficult.
WINE implements the Win32 threading/process and synchronisation model.
It needs to use the OS native threads so it gets the stack maintenance
and the correct handling of the %fs.
So WINE cannot change to pthreads without major hacks to the pthread library
More information about the wine-devel