I think that the first problem is that if foo.exe.so links with libpthread.so, then libpthread.so gets loaded and initialized before ntdll.dll.so is loaded and overrides the pthread functions in the C library -> big trouble.
This migh conceivable be worked around using a wrapper like I described for libmfc.so except this time the wrapper would just load libntdll.so and the wrapped executable would link with libpthread.so.
Then I guess it should work since threaded opengl libraries are supposed to work.
But is there really an advantage to using pthread rather than the Win32 threading functions when porting a Windows application? After all one should not have to change the code when porting with Winelib...
Without SignalObjectAndWait() I imagine that many medium sized to large apps would have to consider alternative threading libraries... the app I'm trying to port uses it quite a bit to prevent race conditions. As an interested party rather than a developer I'd suggest that the effort would be best spent implementing SignalObjectAndWait() before worrying about pthread compatibility, but I don't know the extent of the work involved.
For my own porting project I'm now considering at a "clean" port without any Windows calls - fortunately we only use the thread calls and some file system calls from the Win32 API - but I suspect that this might present a roadblock to other projects hoping for a painless port.
In any case, you folks have done a great job with Wine and winelib, and I thank you for it.
Cheers,
Sean
-
Sean Mitchell