>>>>> On Tue, 27 May 2003 21:49:34 -0400, Camm Maguire <[EMAIL PROTECTED]> said:
Camm> Greetings! GCL uses the above externally defined address in locating Camm> the special second stack on ia64 for the purposes of garbage collection Camm> (standard mark/sweep). All works fine, as long as gcl is run with the Camm> same libc with which it was compiled, otherwise there are symptoms of Camm> memory corruption. As this only occurs on ia64, which is also the only Camm> architecture with this special code in the garbage collector, I Camm> suspect this variable is the culprit, though it could also be some Camm> issue with ld.so on ia64 only, I suppose. Camm> I'd hate to statically link in libc on this arch. Another approach Camm> would be to alter gcl's depends to require the identical libc at Camm> runtime, but this is also less than optimal. I'm hoping that some of Camm> this might ring a bell with someone on this list, and there might be a Camm> better way to locate the stack independently of the libc version. I'd Camm> also like a good way to simulate this other than to wait for a new Camm> libc in unstable and watch for failure :-(. Camm> Any pointers appreciated, Hans Boehm's garbage collector does similar things, so you might want to look at that code for how to handle old (broken) versions of libc. The file to look at is os_dep.c (look for __libc in that file). A tar ball can be found here: http://www.hpl.hp.com/personal/Hans_Boehm/gc/gc_source/gc6.2alpha5.tar.gz Hope this helps, --david
