|
From: | David Chisnall |
Subject: | Re: Please test new NSLock implementation! |
Date: | Wed, 2 Sep 2009 17:10:39 +0100 |
On 2 Sep 2009, at 16:39, Richard Frith-Macdonald wrote:
Any clues on getting this working in mswindows?Grabbing the latest executable from a sourceforge mirror, I put the headers in mingw/include and the libraries in mingw/lib ...That was sufficient for the headers to be found, but I got tis .. Linking library libgnustep-base ... obj/NSLock.m.o: In function `i_NSLock__init':C:/GNUstep/home/richard/devmodules/core/base/Source/NSLock.m:165: undefined reference to `_imp__pthread_mutexattr_init' C:/GNUstep/home/richard/devmodules/core/base/Source/NSLock.m:165: undefined reference to `_imp__pthread_mutexattr_settype' C:/GNUstep/home/richard/devmodules/core/base/Source/NSLock.m:165: undefined reference to `_imp__pthread_mutex_init'and lots more similar messages.I'm guessing that gnustep-make needs updating to find the thread library and add it? Do you know what the link arguments should be?
Gregory built it on Windows last night, so he can answer this better than me, but you probably need to add -lpthread to LD_FLAGS if it's not there already.
Another thing ...do we need to build/use a different version of the objc runtime too? Presumably the runtime needs to be built with the same thread library as the rest of the system.
No. We still use objc_mutex_lock when locking the runtime and we call the relevant runtime functions for registering new threads[1]. The runtime itself never spawns thread and doesn't use anything other than mutexes so it doesn't matter if we mix pthread-wrappers-around-windows- mutexes with objc-wrappers-around-windows-mutexes[2] as long as we don't mix calls (e.g. don't try to use pthread_mutex_lock on the runtime's mutexes or objc_mutex_lock on a pthread mutex). Both wrap win32 mutexes on Windows, so both can be used for synchronisation independently within the same program.
David[1] Note that these functions are complete nonsense. They set two variables, one of which is unused in the runtime and the other is used once in sarray.c, and in the one place where it is used the wrong variable is used so the runtime is only running non-thread-safe code when the number of threads is exactly 1.
[2] This one is particularly stupid, by the way. A mutex on windows is always recursive, but the libobjc abstraction layer assumes that they are not, so implements recursive mutexes on top of non-recursive mutexes on top of recursive mutexes. Yay for coherent design! I will try to fix this soon.
[Prev in Thread] | Current Thread | [Next in Thread] |