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.
