[RFC] pthread emulation on FreeBSD (and Linux)
ovehk at ping.uio.no
Mon Nov 25 01:18:59 CST 2002
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
> 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 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?
More information about the wine-devel