[Ecls-list] Latest changes & request for comments
Michael Abshoff
michael.abshoff at googlemail.com
Mon May 18 14:50:45 UTC 2009
Juan Jose Garcia-Ripoll wrote:
> On Mon, May 18, 2009 at 4:13 PM, Gabriel Dos Reis
Hi Juanjo,
> <gdr at integrable-solutions.net> wrote:
>> But you do not know by the time you produced the file that
>> it is going to be loaded or not going to be loaded. By the time
>> it is loaded it may have been renamed with just the right extension
>> for ECL.
>
> Anyway, as I said, the change has been committed. Please tell me if
> this works for you.
FYI: On Solaris 10 now the uint* types are detectd correctly in the
latest CVS. There is still the problem with isfinite(). I am sorry the
account for the Solaris 10 box hasn't been provided more quickly, but I
am at a conference and we are about to release Sage 4.0 (with ecl
finally :)) in a day or two, so things are more than a little hectic.
> Juanjo
>
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).
--- mach_dep.c.orig 2009-05-18 10:29:14.123591000 -0400
+++ mach_dep.c 2009-05-17 02:27:19.576867000 -0400
@@ -175,7 +175,7 @@
# if defined(HAVE_PUSH_REGS)
GC_push_regs();
# elif defined(UNIX_LIKE) && !defined(DARWIN) && !defined(ARM32) && \
- !defined(HURD)
+ !defined(HURD) && !defined(__mips__)
/* Older versions of Darwin seem to lack getcontext(). */
/* ARM Linux often doesn't support a real getcontext(). */
ucontext_t ctxt;
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
also suspect that many other mips boxen will not ship glibc 2.9 anytime
soon.
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.
Another buglet I ran into is the following. For packaging ecl in Sage I
remove the gc and gmp directory since we ship patched versions/MPIR
which has various fixes and builds properly with assembly on Darwin/x86
for example. I am doing the following:
* copy src/gc/mkinstalldirs to src
* delete gmp and gc directories
* modify src/configure.in:
--- configure.in.orig 2009-05-07 18:24:56.000000000 -0700
+++ configure.in 2009-05-07 18:09:09.000000000 -0700
@@ -11,7 +11,6 @@
AC_INIT([ecl],[9.4.1],[])
AC_REVISION([$Revision$])
AC_CONFIG_SRCDIR([bare.lsp.in])
-AC_CONFIG_AUX_DIR([${srcdir}/gmp])
AC_PREREQ(2.59)
Rerun autoconf and all that goodness.
Then when I set
CPPFLAGS="-I$SAGE_LOCAL/include"; export CPPFLAGS
LDFLAGS="-L$SAGE_LOCAL/lib"; export LDFLAGS
where $SAGE_LOCAL is the prefix for GMP/MPIR and gc. Then running
./configure --prefix=$SAGE_LOCAL --with-system-gmp --enable-boehm=system
followed by make results in dpp.c failing to compile due to missing gc
headers for example. If you look into the appropriate Makefile.in:
$(DPP): $(srcdir)/dpp.c $(srcdir)/symbols_list2.h
if test -f ../CROSS-DPP; then touch dpp; else \
$(TRUE_CC) @CFLAGS@ @ECL_CFLAGS@ -I$(srcdir) -I at true_builddir@
-I./ $(DEFS) $(srcdir)/dpp.c -o $@ ; \
fi
you will see that CFLAGS is defined as
CFLAGS = -c -DECL_API -I. -I at true_builddir@ -I$(srcdir) -I../ecl/gc
@CPPFLAGS@ @CFLAGS@ @ECL_CFLAGS@
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. I assume gmp.h and gc.h are pulled in via '#include
<ecl/config.h>'. I got a manual fix by copying the headers dpp.c needs
to compile, but it seems like a hack. OTOH I am not sure how to fix this
cleanly.
Thanks for your hard work on ECL.
Cheers,
Michael
More information about the ecl-devel
mailing list