Greetings! One more observation here which may be helpful -- on hppa, malloced memory starts at ~ 0x200000 and the stack counts *up* from ~ 0xb0000000. gcl can deal with this without difficulty, except for the fact that variables declared *volatile* have addresses in the 0x7a0000 range. This puts them in the middle of the lisp core, which is sure to messup the gc. I can either try eliminating the volatile declarations, which will likely lead to clobbering errors, or find a way to start malloc and sbrk at say 0x1000000, and treat the 0x7a0000 range as a separate stack for the gc. This looks like the two stack setup on ia64 somewhat. As a third possibility, I could find a way to put volatile variables on the main stack. This would e the easiest of course from gcl's end.
Can anyone advise here? Take care, [EMAIL PROTECTED] (LaMont Jones) writes: > On Fri, Sep 13, 2002 at 10:17:04AM -0400, Camm Maguire wrote: > > Greetings! I think I may have stumbled on a possible explanation for > > gcl's build failure on hppa. Hppa alone will not relocate (i.e. allow > > dlopen to open) modules not compiled with -fPIC. All other > > architectures on which dlopen is currently used (alpha, ia64, mips, > > mipsel) > > Actually, mips and mipsel force -fPIC on all compiles. The spec requires > that shared objects be built with -fPIC. > > > 1) gcl can also relocate and load objects via a direct call to the BFD > > library routine bfd_get_relocated_section_contents. This method is > > currently used as the default on i386, sparc, ppc, s390, m68k and > > arm. It is not yet fully implemented on hppa. Completing this > > routine should enable a fully functional gcl, maxima, and in the > > hopefully near future acl2 on this platform. > > Cool. > > > 2) Find a way to load objects with dlopen without -fPIC. Attempting > > this results in the error that a certain relocation output by the > > compiler cannot be handled by dlopen. Perhaps there is some other > > gcc compiler option short of the full -fPIC which can avoid this > > relocation? > > Nope. The non-PIC is truly not position independent. > > > In either case, I will need a knowledgeable hppa person to advise, > > discuss and help generate patches for this to get fixed any time soon. > > Gcl can build its own bfd library, so patches here can be simply > > incorporated. > > willy would be a good target. I'm going to be out of town for a couple > of weeks, but (if it's still pending) I'd be happy to help when I get > back. > > lamont > > > _______________________________________________ > Gcl-devel mailing list > [EMAIL PROTECTED] > http://mail.gnu.org/mailman/listinfo/gcl-devel > > -- Camm Maguire [EMAIL PROTECTED] ========================================================================== "The earth is but one country, and mankind its citizens." -- Baha'u'llah
