With the attached patch FreeBSD compiles again even if OpenGL (which need pthreads) is used.
Since it is only stubs at present OpenGL can't really work, but Wine and the normal test runs fine ("make test").
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.
This begs the question: Does the Linux implementation of pthread really work anyway?
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.
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.
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.
I'm not really very good on how runtime linking on Linux and FreeBSD. So, I would very much like comments from people more knowledgeable than I on that area.
Comments? Suggestions?
PS. Can somebody test if OpenGL:s pthread locking REALLY works properly on Linux?
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?
Patrik Stridvall ps@leissner.se writes:
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.
I don't think you need a separate library, ntdll should do fine (once scheduler/pthread.c is adapted to work on FreeBSD of course). You just need some default implementation for the missing symbols before they get overriden by ntdll. Does this work for you?
Index: configure.ac =================================================================== RCS file: /opt/cvs-commit/wine/configure.ac,v retrieving revision 1.100 diff -u -r1.100 configure.ac --- configure.ac 23 Nov 2002 01:20:02 -0000 1.100 +++ configure.ac 25 Nov 2002 18:05:47 -0000 @@ -947,6 +947,11 @@ pclose \ popen \ pread \ + pthread_getspecific \ + pthread_key_create \ + pthread_mutex_lock \ + pthread_mutex_unlock \ + pthread_setspecific \ pwrite \ rfork \ select \ Index: library/port.c =================================================================== RCS file: /opt/cvs-commit/wine/library/port.c,v retrieving revision 1.37 diff -u -r1.37 port.c --- library/port.c 18 Oct 2002 00:27:38 -0000 1.37 +++ library/port.c 25 Nov 2002 18:05:53 -0000 @@ -680,6 +680,31 @@
/*********************************************************************** + * pthread functions + */ + +#ifndef HAVE_PTHREAD_KEY_CREATE +int pthread_key_create() { return 0; } +#endif + +#ifndef HAVE_PTHREAD_GETSPECIFIC +int pthread_mutex_getspecific() { return 0; } +#endif + +#ifndef HAVE_PTHREAD_SETSPECIFIC +int pthread_mutex_setspecific() { return 0; } +#endif + +#ifndef HAVE_PTHREAD_MUTEX_LOCK +int pthread_mutex_lock() { return 0; } +#endif + +#ifndef HAVE_PTHREAD_MUTEX_UNLOCK +int pthread_mutex_unlock() { return 0; } +#endif + + +/*********************************************************************** * interlocked functions */ #ifdef __i386__
-
Alexandre Julliard -
Ove Kaaven -
Patrik Stridvall