On Mon, Feb 23, 2009 at 8:05 PM, Ben Lippmeier <[email protected]> wrote: > > On 24/02/2009, at 11:37 AM, Daniel Peebles wrote: >> >> I was told in #ghc on freenode to start with an unregistered build, >> but that seems to fail in compiler/main/DynFlags.hs, as the Platform >> module doesn't work in an unregistered build. > > That'll be my fault. In the Cabal file the Platform.hs module is only > compiled when the NCG is included, but it's also used by Dynflags. I'll > patch it.
Ah, thanks! >> ... but eventually got stuck on rts/sm/GCThread.h, >> which seems to assume that __GNUC__ implies __thread working, which >> isn't true on Mac OS. I tried a few things to get around this but none >> seemed to work. > > I'm not sure what you mean by "seems to assume that __GNUC__ implies > __thread working." > > In rts/sm/GCThread.h, with the line: > > extern __thread gc_thread* gct > > The __thread attribute is supposed to make the "global" variable gct into > thread-local-storage, so each thread has its own private version of it. The > GCC manual page for it is here: > http://gcc.gnu.org/onlinedocs/gcc/Thread_002dLocal.html#Thread_002dLocal > > Ben. > Yeah, but from what I understand of the __thread for thread-local storage, it seems rather ELF-specific. Attempting to compile code that uses it on (my) Mac OS (i.e., MachO instead of ELF) results in a "thread-local storage not supported for this target" error, which according to http://lists.apple.com/archives/xcode-users/2006/Jun/msg00551.html is expected on Mac OS. Given the line of #ifdefs in that file, though, I'm not sure how the thread-local storage works normally for Mac OS. _______________________________________________ Cvs-ghc mailing list [email protected] http://www.haskell.org/mailman/listinfo/cvs-ghc
