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
