Wine, Windows.Forms on Linux, GC and segfaults.

Patrik Stridvall ps at leissner.se
Wed Dec 11 13:58:55 CST 2002


> > 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.

Sure, however Winelib provides a pthread implementation so it should
be possible to get it to work anyway. It currently works for OpenGL so
I can't see why it can't work for libmono and libgc. Sure our pthread
implementation might need some improvements but it should work in 
theory.

Just remove -lpthread from the linking command line and see what happends.
If you get errors about unimplemented functions it is probably because 
Wine's pthread implementation doesn't implement that function yet.

> 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 the long term possibly. However we need a platform independent
solution which at minimum supports Linux, *BSD and Solaris.

> 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?

Well, Winelib uses pthreads on non-x86 platforms, so I guess it would
be possible to do it on x86 as well. However Wine, the emulator part
can't possible work with pthreads because it needs more control than
pthread provides.

In any case, I don't see any reasonable short term solution than to
improve Wine's pthread implementation to support libmono and libgc.
If you are lucky it might work right away. Fingers crossed. :-)



More information about the wine-devel mailing list