On Sun, 24 Nov 2002, Patrik Stridvall wrote:
Anyway, to answer the first obvious question: Why didn't you just put it in scheduler/pthread.c?
Well, the thing is it didn't work. It still generates the same link errors. However that is not very suprising since the pthread_ implementation is in ntdll.dll which is not linked with during the "-Bsymbolic -z defs" step.
scheduler/pthread.c should be linked into libwine, which is linked into everything, at least this is the idea and was the case last time I checked.
It is not so in the current CVS of Wine: scheduler/pthread.c is linked with ntdll not with libwine.
However libwine is not an appropriate place for the pthread implementation since the pthread implementation needs to call Windows API functions. libwine is a strictly Unix API library AFAICS. That why I made a new libwine_pthread library.
This begs the question: Does the Linux implementation of pthread really work anyway?
Works in WineX (though we needed some more hacks in it to make it interact well with the nvidia opengl drivers), and it'd surprise me if it doesn't still work in Wine, as the OpenGL deployed by most linux distros wouldn't work *at all* under Wine if it didn't, and people currently seem to be working on Wine as if it did work.
True. However, while I can't say I really understand how runtime linking work, I still feel that something is wrong.
The thing is Linux (or rather the GNU C library) always links in pthread suppport. However since some of the symbols are on purpose defined as weak they can be overriden. This is what scheduler/pthread.c does on Linux. Or rather tryies to do. I'm not really sure if works any longer.
It's not the weak symbols that allow overrides, weak symbols only allow the pthreads library to *not* be linked in (so your statement about always linking it in is untrue). Weak symbols work such that until the library is linked in, they are just null pointers, and glibc only calls them if they aren't null. Overriding symbols can only be done by linking things in the right order (link the wine overrides before the real pthread lib), and since libwine is loaded before opengl-linked-against-pthreads, the libwine pthread implementation is used instead of the pthreads linked in later, and this don't need a special kind of symbol to work.
OK. Thanks for the explaination. As I said not my area or expertise.
Note that if I apply the attach patch and compiles on Linux it seems to work with "make test" as well.
Anyway be pthreads on Linux working properly as it may, the big question is how do we support pthreads on both Linux and FreeBSD.
I'd say link -lwine in before -lc_r, but then I don't know much about FreeBSD.
It is already done that what eventhough: 1. We current link with -lc not -lc_r, but maybe we should. 2. scheduler/pthread.c is as I said earlier in ntdll not libwine, so I can't see how linking can work and futhermore is doesn't for empirical evidence.
FreeBSD since it AFAICS have no default overridable implementation seems to require that we have some sort of wine_pthread library to implement pthreads from scratch like outlined in the attached patch.
The scheduler/pthread.c is basically the same thing, since it needs to override every single pthread symbol used by apps, otherwise the override fails (or if it would be successful, it would still be incomplete).
Stupid question: the reason for the missing symbols on FreeBSD isn't because of the #ifdef __GLIBC__ in scheduler/pthread.c, is it?
No, I would have to be VERY tired to make that mistake. :-)
But since your premise scheduler/pthread.c in libwine is wrong that might be the answer. However it still doesn't explain why OpenGL seems to work on Linux. Perhaps it is because Linux have weak symbols or whatever concerning pthreads in libc and everything is OK because of this...