[Ecls-list] Latest changes & request for comments
Michael Abshoff
michael.abshoff at googlemail.com
Mon May 18 16:03:56 UTC 2009
Juan Jose Garcia-Ripoll wrote:
> On Mon, May 18, 2009 at 4:50 PM, Michael Abshoff
> <michael.abshoff at googlemail.com> wrote:
Hi Juan,
>> FYI: On Solaris 10 now the uint* types are detectd correctly in the latest
>> CVS. There is still the problem with isfinite().
>
> Ok, it is good to read that the problems become better defined.
Yes, the finite() vs. isfinite() issue can be solved by pulling in
"ieeefp.h" on Solaris/x86 and defining isfinite appropriately. I am sure
Gaby will tell which autoconf macro to use :)
>> I am sorry the account for
>> the Solaris 10 box hasn't been provided more quickly
>
> No problem, I can wait. In the mean time I will try to build an open
> solaris image myself. Last time I tried it was even impossible to boot
> the OS using a virtual machine.
>
>> but I am at a
>> conference and we are about to release Sage 4.0 (with ecl finally :))
>
> Good news!
Yep, it is a great day for Sage to finally get rid of clisp :). With
some recent fedora core releases clisp tends to fail to mmap memory on
startup somewhere around 1/100 to 1/200 cases, so Sage would fail to
pass doctests since Maxima crashes. clisp on Itanium, especially RHEL is
basically broken since at least 2.41. 2.47 builds some times, but 2 out
of 3 times crahes on SLES 10/Itanium even with unlimited stack and let's
not even talk about linux/mips, Solaris or MSVC on Windows while ecl
aside from Solaris 10/x86 works like a charm and even more importantly I
can fix build issues in the C bits in minutes ;).
>> Anyway, I build Maxima+ecl on a mips64 box and boehm gc need the following
>> fix to build due to getcontext() not being provided on Linux/mips64 (maybe
>> even mips). [...] If you google around you will find that this has been fixed on linux/mips
>> for glibc 2.9 and there is a backport of the fix in glibc 2.7 for Debian,
>> but I am running things on a SiCortex which runs Gentoo
>
> I have pushed this fixed into our local gc tree.
Cool.
>> You also need to build boehm_gc on that platform without threading - at
>> least with the 7.1 release you have in tree (and which also seems to be the
>> most recent stable release). I should let upstream boehm_gc know about the
>> fix to see if they will accept it.
>
> As I said, this is getting pushed into ECL's tree. It is not the first
> time we temporarily include a fix for a platform and wait for gc to
> catch up.
Sure, it was mostly meant as a public reminder to get it upstream.
>> Another buglet I ran into is the following. [...] I am doing the following:
>>
>> * copy src/gc/mkinstalldirs to src
>> * delete gmp and gc directories
>> * modify src/configure.in:
>>
>> CPPFLAGS="-I$SAGE_LOCAL/include"; export CPPFLAGS
>> LDFLAGS="-L$SAGE_LOCAL/lib"; export LDFLAGS
>>
>> Now the include directive for the headers should have been pulled in via
>> @CPPFLAGS@, but it isn't. If I add it manually for $(DPP) things blow up.
>
> The value of CPPFLAGS was not used when building dpp. I have fixed this as well.
Thanks. For some reason adding it for me always caused errors when
building the first ecl file after ecl, but I might have been using the
wrong autohell release. Anyway, I will pull from CVS/git and give it a
spin soon.
> Juanjo
>
Cheers,
Michael
More information about the ecl-devel
mailing list