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