[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