Greetings! Thought I'd give a brief update here. gcl/maxima is now
very close to running without issue on all 11 Debian architectures!
When this round of porting is wrapped up, hopefully in a few days,
I'll post another update, which should then be somewhat constant as we
turn attention to missing features.
P.S. -- it sure would be nice to get rid of those pejorative comments
regarding gcl in maxima's README.lisps :-)
Camm Maguire <camm@enhanced.com> writes:
> cpu OS BFD SGC compile max5.6 5.6test Note:
> (kernels)
>
> x86 Linux yes all pass pass pass
> ppc Linux yes 2.4x pass pass pass (1)
> sparc Linux yes 2.4x pass pass pass (2)
> m68k Linux yes all no no no (2.5)
> arm Linux yes no pass pass pass (3)
> s390 Linux yes 2.4x pass pass pass (4)
>
> mips Linux no all? pass pass pass (5)
> mipsel Linux no all? pass pass pass (5)
>
> alpha Linux no no pass pass pass (6)
> ia64 Linux no no pass pass pass (6)
> hppa Linux no no no no no (6)
>
> sparc solaris yes yes pass pass two errors (7)
>
> x86 w32 no yes pass pass (8)
>
> ??? xBSD ??? ??? ???? ???? ???? (9)
> ??? osX ??? ??? ???? ???? ???? (9)
>
>
>
>
> (1) at least with kernels 2.4.x, SGC relies on siginfo_t here
> (2) sparc seems to honor siginfo_t in newer kernels, but apparently
> minor issue remains in sgbc.c with PTR_ALIGN being set to 8.
UPDATE: Issue now resolved, sparc running SGC.
(2.5) UPDATE: In cleaning up -Wall, I broke this build, as it
apparently treats functions returning pointers differently
from those returning integers. A straightforward hack should
restore this build, but I'd like to do something cleaner. It
would require changing the compiler to declare all functions
returning object, with a cast of any long integers into an
object at function return. The issue is one of performance --
gcl avoids unnecessary make_fixnum accesses to the memory
manager when a temporary integer is simply briefly sought.
> (3) UPDATE: sigill resolved.
> (4) should work with 2.4.x, cannot yet test. Can you test for me,
> Gerhard?
UPDATE: can run SGC, if work out a way to detect kernel 2.2.x.
> (5) mips/mipsel should be fully functional once the relocation
> support in the bfd library is finished, or I get around to
> writing a workaround. MIPS_GOT16 relocs are not currently
> handled by the bfd. Any knowledgeable mips people interested?
UPDATE: mips(el) now use dlopen for object loading. This is
hopefully temporary, but must wait on a patch to bfd.
> (6) all these 64bit ports compile, but likely still have a few issues
> with sizeof(int)
UPDATE: all (known) 64bit issues resolved. Alpha and ia64 work
without problem. hppa still has a gc issue. Same bfd
situation as mips(el)
> (7) Dan, can you chase these down in a debugger? What about 5.9 on
> solaris?
UPDATE: Dan you were waiting on a clean -Wall build before
looking into this. We have this now. Can you please report?
> (8) Mike, would like to know if bfd and/or sgc are working for you.
> (9) Anyone looking at these?
>
> Take care,
--
Camm Maguire camm@enhanced.com
==========================================================================
"The earth is but one country, and mankind its citizens." -- Baha'u'llah