Do we have an IBM VME for OS X? :-) Best Regards Sean, Xiao Xia Qiu
2009/6/29 Mark Hindess <mark.hind...@googlemail.com>: > > In message <3b3f27c60906280859m350545bdg899c85e77c96d...@mail.gmail.com>, > Nathan Beyer writes: >> >> I've been playing around trying to port the portlib cod to run on >> Mac OS X 10.5. I've been futzing around with the assembly file in >> 'thread', specifically 'thrhelp.s' and 'thrspinlock.s'. I've been >> trying to find the lowest common denominator to work on Linux an OS X, >> but I've finally come to the conclusion that it's just not going to >> happen. Although most of the actual code - the implementations of the >> method are directly portable, the small stuff around it just doesn't >> work. >> >> The main issue revolves around leading underscores being added >> to function names. Apparently, this isn't the default behaviour >> for Linux, but it is on OS X - even though I'm using gcc and gas >> in both case. As such, the function names in the assembly files >> need to be different based on the OS. I've tried fiddling with the >> '-fno-leading-underscores' flag, but this blows up other stuff and >> just seems to be a rat hole. > > Nathan, you are running down the wrong rat hole. > > DRLVM doesn't use the threading code in classlib so fixing it is futile. > DRLVM provides its own libhythr.so - using the src in vm/thread/src. > > I've never understood why we have a hy.thr.nodeploy option for the > classlib thread code. If we aren't going to deploy it, why are we > building it? > > (Aside: the originally contributed assembler code in classlib for > linux/x86 works but the later, Intel-contributed assembler code for > linux/x86_64 links but does not actually work in practice.) > >> At this point, I think it's time to give up on the os.family + os.arch >> separation and change to os.name + os.arch or something else? Any >> thoughts or suggestions on such a change? I'm curious how this stuff >> works on the other unix platforms, such as AIX and BSD. > > Well, the IBM VME for Aix uses the -Dhy.no.thr=true option so the > classlib threading code is not used. But when I last tested it the > assembler code for x86 worked on FreeBSD. However, this wouldn't stop > us splitting the code by os.name, we'd just use #include's to share > implementation where possible - much like we do with the hymmap.c code. > > Regards, > Mark. > > >
