Opened 9 years ago

Closed 9 years ago

Last modified 9 years ago

#11884 closed defect (fixed)

Fix ECL so it builds on OS X Lion

Reported by: jhpalmieri Owned by: tbd
Priority: blocker Milestone: sage-4.7.2
Component: packages: standard Keywords: ecl spkg upgrade update lion darwin 11
Cc: mhansen, leif Merged in: sage-4.8.alpha3
Authors: Dmitrii Pasechnik, Mike Hansen, Karl-Dieter Crisman, William Stein, John Palmieri, Jeroen Demeyer Reviewers: Karl-Dieter Crisman, Reg Burgess, François Bissey, Leif Leonhardy, John Palmieri
Report Upstream: Fixed upstream, but not in a stable release. Work issues:
Branch: Commit:
Dependencies: #11966 Stopgaps:

Status badges

Description (last modified by jdemeyer)

As the summary says.

The home base for this ticket is the Lion ticket #11881.

There are no claims that this fixes Maxima building (see #11966 for that); the only claim is that this new package builds and ecl runs standalone.

spkg: http://boxen.math.washington.edu/home/jdemeyer/spkg/ecl-11.1.2.cvs20111120.p0.spkg (also contains the fixes for Cygwin, see #11119)

This package, and Maxima built with it, works on:

  1. OS X 10.4 PPC
  2. OS X 10.6
  3. OS X 10.7
  4. sage.math.washington.edu

The CVS version from 2011-11-08 fails on OS X 10.4 PPC, reported upstream.

Attachments (4)

trac_11884-ecl.delta.patch (6.5 KB) - added by jhpalmieri 9 years ago.
diff between previous version and this one
trac_11884-ecl.patch (10.3 KB) - added by jhpalmieri 9 years ago.
patch for ecl spkg; for review only
ecl-11.1.2.git.20111030.p0.log (327.7 KB) - added by jdemeyer 9 years ago.
Build failure on OS X 10.4 PPC
ecl-11.1.2.cvs20111115.diff (4.4 KB) - added by jdemeyer 9 years ago.
Diff between ecl-11.1.2.git.20111030.p0.spkg and ecl-11.1.2.cvs20111115.p0.spkg

Download all attachments as: .zip

Change History (73)

comment:1 follow-up: Changed 9 years ago by jhpalmieri

  • Cc mhansen added

I got this to build by pulling from their latest repository:

git clone git://ecls.git.sourceforge.net/gitroot/ecls/ecl

Then I dropped this as "src" into the old ecl spkg. Should I make an official spkg this way? It would feel safer to just extract the changes that we need, but I'm not sure I have time to look into that right now.

(My build hasn't reached maxima yet, either, so I don't know if ecl will really work or not.)

comment:2 Changed 9 years ago by jhpalmieri

No, maxima didn't build:

An error occurred during initialization:
In C:BUILDER, when building file
 binary-ecl/maxima
tried to link together files that contained split binary data.
Unfortunately this is currently not possible. To avoid this
recompile the files setting C::*COMPILE-IN-CONSTANTS* to T.
List of offending files:

and then a long list of files follows. Suggestions?

comment:3 Changed 9 years ago by jhpalmieri

On the other hand, the binary "ecl" starts and executes some basic lisp operations correctly. So do we need to modify the maxima spkg?

comment:4 Changed 9 years ago by leif

  • Cc leif added
  • Keywords spkg upgrade update darwin 11 added
  • Summary changed from fix ecl so it builds on OS X Lion to Fix ECL so it builds on OS X Lion

comment:5 in reply to: ↑ 1 Changed 9 years ago by kcrisman

I got this to build by pulling from their latest repository: git clone git://ecls.git.sourceforge.net/gitroot/ecls/ecl

Ah, so that's where it lives... I'm putting a link on #11119.

comment:6 Changed 9 years ago by kcrisman

Also, here are three links to relevant threads on the ECL list.

comment:7 Changed 9 years ago by kcrisman

None of which address getting Maxima to build, of course. We could ask Juanjo (who does have a Trac account, I think, though I can't find it) or the ECL list.

comment:8 Changed 9 years ago by kcrisman

  • Description modified (diff)

comment:9 Changed 9 years ago by was

I made an spkg (link in the ticket description) with this log message:

=== ecl-11.1.2.git.20111030 (William Stein, 30th October 2011) ===
  * Upgraded for trac 11884.   I got this by using

       git clone git://ecls.git.sourceforge.net/gitroot/ecls/ecl
       rm -rf src
       mv ecl src
       cd ecl; rm -rf .git*    # remove saved 20MB

    I'm calling it 11.1.2.git so that the version number still sorts
    correctly, and since one could view this as a snapshot of what
    will be 11.1.2 eventually.

comment:10 Changed 9 years ago by was

  • Description modified (diff)
  • Status changed from new to needs_review

With http://sage.math.washington.edu/home/wstein/patches/ecl-11.1.2.git.20111030.spkg

deep:sage-4.7.3.alpha1 wstein$ ./sage -lisp
ECL (Embeddable Common-Lisp) 11.1.1 (git:UNKNOWN)
Copyright (C) 1984 Taiichi Yuasa and Masami Hagiya
Copyright (C) 1993 Giuseppe Attardi
Copyright (C) 2000 Juan J. Garcia-Ripoll
ECL is free software, and you are welcome to redistribute it
under certain conditions; see file 'Copyright' for details.
Type :h for Help.  
Top level.
> (+ 2 3)

5

comment:11 Changed 9 years ago by was

In fact, as John says above, even with this version of ECL, the Maxima spkg definitely finishes with a failure (for me, after 11 minutes). This is the message in the error.log (it's just more details of what John wrote above):

An error occurred during initialization:
In C:BUILDER, when building file
 binary-ecl/maxima
tried to link together files that contained split binary data.
Unfortunately this is currently not possible. To avoid this
recompile the files setting C::*COMPILE-IN-CONSTANTS* to T.
List of offending files:
 #P"binary-ecl/maxima-package.o"
 #P"binary-ecl/ecl-port.o"
 #P"binary-ecl/autoconf-variables.o"
 #P"binary-ecl/nregex.o"
...
 #P"binary-ecl/share-subdirs.o"
 #P"binary-ecl/init-cl.o".
make[1]: *** [binary-ecl/maxima] Error 1
make: *** [all-recursive] Error 1

}}}

comment:12 Changed 9 years ago by was

  • Description modified (diff)

comment:13 Changed 9 years ago by kcrisman

William seems to have a fix for Maxima as well at #11966, just fyi to those reading.

comment:14 Changed 9 years ago by kcrisman

Just a question as to whether there are any patches in previous versions that are still needed. This does seem to be based on #11119, but I'm a little surprised that the patches from that still apply (and are still in spkg-install), if this is really based on the latest ECL, since they are basically from upstream.

comment:15 follow-ups: Changed 9 years ago by leif

  • Authors set to William Stein
  • Reviewers set to Leif Leonhardy
  • Status changed from needs_review to needs_work
== Special Update/Build Instructions ==
 * Delete the contents of the src/msvc directory
 * Delete the contents of the src/contrib/encodings/

There seems to be additional crap (or redundant things) in the upstream tree.

You should have noticed that even the compressed spkg is now almost twice as large.


What Karl-Dieter said is most probably because the exit codes of patch aren't checked:

###############################################################
# apply patch for the problem acknowledged upstream in
# http://www.mail-archive.com/ecls-list@lists.sourceforge.net/msg00671.html
# The patch itself comes from the following commit:
# http://ecls.git.sourceforge.net/git/gitweb.cgip=ecls/ecl;a=commit;h=ce19c67a1b9f63cd32e7c0a621b6ca87aaa7214
###############################################################
cd src
patch -p0 < ../patches/ecls-11.1.1-cmploc.lisp.patch

# apply patches for Cygwin build
# these patches is in ECL CVS, remove upon upgrade
# Cygwin also has upstream fixes that are closely related, keep track
# See Trac 11119
patch -p0 < ../patches/libraries.d.patch
patch -p0 < ../patches/unixint.d.patch
patch -p0 < ../patches/math_fenv.h.patch

if [ "x$CFLAG64" = x ] ; then
    ...

Who reviewed these spkgs? 8/

comment:16 in reply to: ↑ 15 Changed 9 years ago by leif

Replying to leif:

== Special Update/Build Instructions ==
 * Delete the contents of the src/msvc directory
 * Delete the contents of the src/contrib/encodings/

There seems to be additional crap (or redundant things) in the upstream tree.

$ diff -qr ecl-11.1.1.p3/src/ ecl-11.1.2.git.20111030/src/ | grep -i only
Only in ecl-11.1.1.p3/src/: .gitignore
Only in ecl-11.1.2.git.20111030/src/contrib/encodings: ATARIST.BIN
Only in ecl-11.1.2.git.20111030/src/contrib/encodings: CP-856.BIN
Only in ecl-11.1.2.git.20111030/src/contrib/encodings: DOS-CP437.BIN
Only in ecl-11.1.2.git.20111030/src/contrib/encodings: DOS-CP737.BIN
Only in ecl-11.1.2.git.20111030/src/contrib/encodings: DOS-CP775.BIN
Only in ecl-11.1.2.git.20111030/src/contrib/encodings: DOS-CP850.BIN
Only in ecl-11.1.2.git.20111030/src/contrib/encodings: DOS-CP852.BIN
Only in ecl-11.1.2.git.20111030/src/contrib/encodings: DOS-CP855.BIN
Only in ecl-11.1.2.git.20111030/src/contrib/encodings: DOS-CP857.BIN
Only in ecl-11.1.2.git.20111030/src/contrib/encodings: DOS-CP860.BIN
Only in ecl-11.1.2.git.20111030/src/contrib/encodings: DOS-CP861.BIN
Only in ecl-11.1.2.git.20111030/src/contrib/encodings: DOS-CP862.BIN
Only in ecl-11.1.2.git.20111030/src/contrib/encodings: DOS-CP863.BIN
Only in ecl-11.1.2.git.20111030/src/contrib/encodings: DOS-CP864.BIN
Only in ecl-11.1.2.git.20111030/src/contrib/encodings: DOS-CP865.BIN
Only in ecl-11.1.2.git.20111030/src/contrib/encodings: DOS-CP866.BIN
Only in ecl-11.1.2.git.20111030/src/contrib/encodings: DOS-CP869.BIN
Only in ecl-11.1.2.git.20111030/src/contrib/encodings: DOS-CP874.BIN
Only in ecl-11.1.2.git.20111030/src/contrib/encodings: ISO-2022-JP
Only in ecl-11.1.2.git.20111030/src/contrib/encodings: ISO-2022-JP-1
Only in ecl-11.1.2.git.20111030/src/contrib/encodings: ISO-8859-1.BIN
Only in ecl-11.1.2.git.20111030/src/contrib/encodings: ISO-8859-10.BIN
Only in ecl-11.1.2.git.20111030/src/contrib/encodings: ISO-8859-11.BIN
Only in ecl-11.1.2.git.20111030/src/contrib/encodings: ISO-8859-13.BIN
Only in ecl-11.1.2.git.20111030/src/contrib/encodings: ISO-8859-14.BIN
Only in ecl-11.1.2.git.20111030/src/contrib/encodings: ISO-8859-15.BIN
Only in ecl-11.1.2.git.20111030/src/contrib/encodings: ISO-8859-16.BIN
Only in ecl-11.1.2.git.20111030/src/contrib/encodings: ISO-8859-2.BIN
Only in ecl-11.1.2.git.20111030/src/contrib/encodings: ISO-8859-3.BIN
Only in ecl-11.1.2.git.20111030/src/contrib/encodings: ISO-8859-4.BIN
Only in ecl-11.1.2.git.20111030/src/contrib/encodings: ISO-8859-5.BIN
Only in ecl-11.1.2.git.20111030/src/contrib/encodings: ISO-8859-6.BIN
Only in ecl-11.1.2.git.20111030/src/contrib/encodings: ISO-8859-7.BIN
Only in ecl-11.1.2.git.20111030/src/contrib/encodings: ISO-8859-8.BIN
Only in ecl-11.1.2.git.20111030/src/contrib/encodings: ISO-8859-9.BIN
Only in ecl-11.1.2.git.20111030/src/contrib/encodings: JISX0201.BIN
Only in ecl-11.1.2.git.20111030/src/contrib/encodings: JISX0208.BIN
Only in ecl-11.1.2.git.20111030/src/contrib/encodings: JISX0212.BIN
Only in ecl-11.1.2.git.20111030/src/contrib/encodings: KOI8-R.BIN
Only in ecl-11.1.2.git.20111030/src/contrib/encodings: KOI8-U.BIN
Only in ecl-11.1.2.git.20111030/src/contrib/encodings: SHIFT-JIS.BIN
Only in ecl-11.1.2.git.20111030/src/contrib/encodings: WINDOWS-CP1250.BIN
Only in ecl-11.1.2.git.20111030/src/contrib/encodings: WINDOWS-CP1251.BIN
Only in ecl-11.1.2.git.20111030/src/contrib/encodings: WINDOWS-CP1252.BIN
Only in ecl-11.1.2.git.20111030/src/contrib/encodings: WINDOWS-CP1253.BIN
Only in ecl-11.1.2.git.20111030/src/contrib/encodings: WINDOWS-CP1254.BIN
Only in ecl-11.1.2.git.20111030/src/contrib/encodings: WINDOWS-CP1255.BIN
Only in ecl-11.1.2.git.20111030/src/contrib/encodings: WINDOWS-CP1256.BIN
Only in ecl-11.1.2.git.20111030/src/contrib/encodings: WINDOWS-CP1257.BIN
Only in ecl-11.1.2.git.20111030/src/contrib/encodings: WINDOWS-CP1258.BIN
Only in ecl-11.1.2.git.20111030/src/contrib/encodings: WINDOWS-CP932.BIN
Only in ecl-11.1.2.git.20111030/src/contrib/encodings: WINDOWS-CP936.BIN
Only in ecl-11.1.2.git.20111030/src/contrib/encodings: WINDOWS-CP949.BIN
Only in ecl-11.1.2.git.20111030/src/contrib/encodings: WINDOWS-CP950.BIN
Only in ecl-11.1.2.git.20111030/src/contrib/encodings: generate.lisp
Only in ecl-11.1.2.git.20111030/src/contrib/encodings: tools.lisp
Only in ecl-11.1.2.git.20111030/src/contrib/unicode: ucd16.dat
Only in ecl-11.1.2.git.20111030/src/examples/asdf: example.asd
Only in ecl-11.1.2.git.20111030/src/msvc: Makefile
Only in ecl-11.1.2.git.20111030/src/msvc: c
Only in ecl-11.1.2.git.20111030/src/msvc: doc
Only in ecl-11.1.2.git.20111030/src/msvc: ecl
Only in ecl-11.1.2.git.20111030/src/msvc: gc
Only in ecl-11.1.2.git.20111030/src/msvc: gmp
Only in ecl-11.1.2.git.20111030/src/msvc: util
Only in ecl-11.1.2.git.20111030/src/src/c/ffi: cdata.d
Only in ecl-11.1.2.git.20111030/src/src/c/ffi: mmap.d
Only in ecl-11.1.2.git.20111030/src/src/c: unicode
Only in ecl-11.1.2.git.20111030/src/src/cmp: cmpos-features.lsp
Only in ecl-11.1.1.p3/src/src/gc: MacProjects
Only in ecl-11.1.2.git.20111030/src/src/gc: MacProjects.sit.hqx
Only in ecl-11.1.2.git.20111030/src/src: gc-unstable
Only in ecl-11.1.2.git.20111030/src/src: libffi
Only in ecl-11.1.2.git.20111030/src/src/lsp: cdr-5.lsp
Only in ecl-11.1.2.git.20111030/src/src/lsp: unicode.lsp

comment:17 in reply to: ↑ 15 Changed 9 years ago by leif

Replying to leif:

What Karl-Dieter said is most probably because the exit codes of patch aren't checked [...]

...
Deleting directories from past builds of previous/current versions of ecl-11.1.2.git.20111030
Extracting package /home/leif/Sage/spkgs/ecl-11.1.2.git.20111030.spkg ...
-rw-r--r-- 1 leif leif 7129205 2011-10-31 22:13 /home/leif/Sage/spkgs/ecl-11.1.2.git.20111030.spkg
Finished extraction
...
****************************************************
patching file src/cmp/cmploc.lsp
Reversed (or previously applied) patch detected!  Assume -R? [n] 
Apply anyway? [n] 
Skipping patch.
3 out of 3 hunks ignored -- saving rejects to file src/cmp/cmploc.lsp.rej
patching file src/c/ffi/libraries.d
Hunk #1 succeeded at 70 with fuzz 2 (offset 1 line).
patching file src/c/unixint.d
Reversed (or previously applied) patch detected!  Assume -R? [n] 
Apply anyway? [n] 
Skipping patch.
1 out of 1 hunk ignored -- saving rejects to file src/c/unixint.d.rej
patching file src/h/impl/math_fenv.h
Reversed (or previously applied) patch detected!  Assume -R? [n] 
Apply anyway? [n] 
Skipping patch.
1 out of 1 hunk ignored -- saving rejects to file src/h/impl/math_fenv.h.rej
Using CC=gcc-4.5.1
...

comment:18 Changed 9 years ago by jhpalmieri

I can't tell if we need the (new) directory src/src/libffi. I'll build spkgs with and without and see what happens.

comment:19 in reply to: ↑ 15 Changed 9 years ago by jhpalmieri

Replying to leif:

Delete the contents of the src/contrib/encodings/

This new spkg actually doesn't build if you remove src/contrib/encodings. I get an error message like

;;; Note:
;;;   Invoking external command:
;;;   gcc -o rt.fas -L/Applications/sage_builds/clean/sage-4.7.3.alpha1.osx10.7/spkg/build/ecl-11.1.2.git.20111030.p1/src/build/ /Applications/sage_builds/clean/sage-4.7.3.alpha1.osx10.7/spkg/build/ecl-11.1.2.git.20111030.p1/src/build/eclinitwt8UWf.o ext/rt.o -bundle -L/Applications/sage_builds/clean/sage-4.7.3.alpha1.osx10.7/local/lib -L/Applications/sage_builds/clean/sage-4.7.3.alpha1.osx10.7/local/lib libecl.dylib -lm -lgmp -lgc 
Condition of type: FILE-ERROR
Filesystem error with pathname #P"EXT:ENCODINGS;GENERATE.LISP.NEWEST".

It seems that we can delete some other stuff and still have it build on OS X Lion. I'll make a new spkg soon.

comment:20 Changed 9 years ago by jhpalmieri

  • Description modified (diff)
  • Status changed from needs_work to needs_review

New spkg available. Not tested very extensively, but it seems to build on Lion.

comment:21 Changed 9 years ago by jhpalmieri

  • Dependencies set to #11966

On all the systems on which I've tried, e.g., sage.math or silius, the current maxima package fails to build with this. (The same was true with William's spkg.) I think we will need to upgrade maxima at the same time as ecl, so I'm making #11966 a dependency for this.

(This makes for a circular path of dependencies; is this the right way to ensure that these get merged simultaneously?)

comment:22 Changed 9 years ago by jhpalmieri

  • Status changed from needs_review to needs_work

This needs work, and I don't know how to fix it. On sage.math, I took a vanilla Sage 4.7.2 and dropped in either my spkg or William's, along with the maxima spkg from #11966, and I built from scratch. The build succeeded, but doctesting hangs on various files. For example:

$ ./sage -t --verbose devel/sage/doc/en/tutorial/tour_rings.rst

...
Trying:
    pi in RR###line 124:_sage_    >>> pi in RR
Expecting:
    True

Condition of type: SIMPLE-TYPE-ERROR
In function MAKE-FOREIGN-DATA-FROM-ARRAY, the value of argument is
        "\"3.141592653589793 = %pi\""
which is not of expected type BASE-STRING
Available restarts:

1. (USE-VALUE) Supply a new value of type BASE-STRING.

Top level.
> 

At this point, ecl stops to ask for user input, and since doctesting is noninteractive, it waits until the test times out. For what it's worth, I tried a build which was 4.7.2 plus the maxima spkg from #11966, and all tests passed. So the problem looks like it's ecl, not maxima, but I'm not positive about this.

From the web page http://ecls.sourceforge.net/ecl/Strings.html, it looks like a "base-string" is just an alias for "string", and I don't know why the quoted object isn't a string. Is it the backslashes?

I don't know much about Sage's interactions with ecl and maxima, so I don't have any ideas about how to fix this. The file devel/sage/sage/interfaces/lisp.py passes tests. interfaces/maxima.py passes, but interfaces/maxima_lib.py and interfaces/maxima_abstract.py hang with the same kind of error (when run verbosely).

comment:23 Changed 9 years ago by jhpalmieri

Now I have an idea: the default option for the configure option --enable-unicode changed from "no" to "yes", and that may be the issue, as alluded to here. I'm switching it back to see if that helps. If the current build works and passes tests on sage.math, I'll post a new spkg and patch file.

comment:24 follow-up: Changed 9 years ago by jhpalmieri

  • Status changed from needs_work to needs_review

Yes, that fixed it, at least on sage.math. New spkg up. Differences:

  • SPKG.txt

    diff --git a/SPKG.txt b/SPKG.txt
    a b Website: http://ecls.sourceforge.net/ 
    5151== Changelog ==
    5252
    5353=== ecl-11.1.2.git.20111030.p0 (John H. Palmieri, 2 Novemer 2011) ===
    54   * Trac #11884: general clean-up: remove unneeded patches,
     54  * Trac #11884.  General clean-up: remove unneeded patches,
    5555    remove some source files (as described above in "Special
    56     Update/Build Instructions").  Also check the error code when
    57     running 'patch' in spkg-install.
     56    Update/Build Instructions").
     57  * Check the error code when running 'patch' in spkg-install.
     58  * Run configure with the option "--enable-unicode=no" -- this was
     59    the default in previous versions of ecl, and using the new default
     60    of "yes" causes problems with some strings.
    5861
    5962=== ecl-11.1.2.git.20111030 (William Stein, 30th October 2011) ===
    6063  * Upgraded for trac 11884.   I got this by using
  • spkg-install

    diff --git a/spkg-install b/spkg-install
    a b if [ "x`uname -sm`" = "xSunOS i86pc" ] & 
    9090   # 1) Solaris, Solaris Express or OpenSolaris (SunOS)
    9191   # 2) Intel or AMD CPU
    9292   # 3) 64-bit build
    93    ./configure --prefix="$SAGE_LOCAL" --with-dffi=no
     93   ./configure --prefix="$SAGE_LOCAL" --with-unicode=no --with-dffi=no
    9494else
    95    ./configure --prefix="$SAGE_LOCAL"
     95   ./configure --prefix="$SAGE_LOCAL" --with-unicode=no
    9696fi
    9797
    9898if [ $? -ne 0 ]; then

By the way, I deleted the directory src/src/libffi directory, and this gives a warning during configuration:

checking for ffi_closure_alloc in -lffi... no
checking whether we can use the existing libffi library ... no
configure: Configuring included libffi library:
/scratch/palmieri/ECL/sage-4.7.2/spkg/build/ecl-11.1.2.git.20111030.p0/src/src/configure: line 7012: /scratch/palmieri/ECL/sage-4.7.2/spkg/build/ecl-11.1.2.git.20111030.p0/src/src/libffi/configure: No such file or directory
configure: WARNING: Unable to configure or find libffi library; disabling dynamic FFI

I wonder if we should configure using --with-dffi=no on all platforms? Or perhaps I shouldn't delete the directory. In William's package:

$ du -s -h src
44M	src
$ du -s -h src/src/libffi/
7.2M	src/src/libffi/

So it takes a fair amount of room...

comment:25 Changed 9 years ago by jhpalmieri

Oops: typo in spkg-install: change --with-unicode=... to --enable-unicode=.... Fixed in the new spkg.

comment:26 in reply to: ↑ 24 ; follow-up: Changed 9 years ago by leif

Replying to jhpalmieri:

By the way, I deleted the directory src/src/libffi directory, and this gives a warning during configuration [...]

I wonder if we should configure using --with-dffi=no on all platforms? Or perhaps I shouldn't delete the directory.

libffi is installed on many systems, so we certainly shouldn't disable it.


$ du -s -h src
44M	src
$ du -s -h src/src/libffi/
7.2M	src/src/libffi/

So it takes a fair amount of room...

Much more worth is (also) removing the gmp directory, which at the moment makes up half of the tarball; see #9493. One should at least add a TODO, since people apparently tend to not look at other related tickets.


If you configure with --enable-unicode=no (you could also use --disable-unicode btw.), you can completely remove the following two directories (not just their contents):

src/contrib/encodings/
src/contrib/unicode/


If the patches are applied from src/, they should be applied (i.e., be appliable) with -p1 for consistency.

I also get

patching file src/c/ffi/libraries.d
Hunk #1 succeeded at 70 with fuzz 2 (offset 1 line).


spkg-install in whole needs some clean-up, for example all error messages should go to stderr. If MAKEFLAGS are a problem on MacOS X, they should be unset on MacOS X, not by default (and the comment is btw. wrong or unrelated). We do not create a symbolic link to the ECL library, but the ECL library directory, so the error message is wrong. ...


Ceterum censeo we should upgrage trac.

comment:27 in reply to: ↑ 26 Changed 9 years ago by leif

Replying to leif:

Much more worth is (also) removing the gmp directory, which at the moment makes up half of the tarball; see #9493. One should at least add a TODO, since people apparently tend to not look at other related tickets.

If you hesitate to patch configure to remove / modify the calls of some redundant scripts in src/src/gmp/, you can delete everything there except install-sh and {config,configfsf}.*.

We should also configure with --with-gmp="$SAGE_LOCAL" (or --with-gmp-prefix="$SAGE_LOCAL", haven't tested that yet).


If you configure with --enable-unicode=no (you could also use --disable-unicode btw.), you can completely remove the following two directories (not just their contents):

src/contrib/encodings/
src/contrib/unicode/

FWIW, #9493 had a comment on that one must not configure with --enable-unicode if these directories are deleted (in the Special Update/Build? Instructions section).


Since Sage also ships and builds the Boehm GC, we could most probably delete even more.

comment:28 Changed 9 years ago by jhpalmieri

  • Authors changed from William Stein to William Stein, John Palmieri
  • Milestone changed from sage-4.8 to sage-4.7.2

Okay, I'm posting a new spkg. Differences between the previous one and this one are recorded in the "delta" patch.

libffi is installed on many systems, so we certainly shouldn't disable it.

Okay, I'm not disabling it, so if it's present on the system, it will be used. I'm still removing the directory.

Much more worth is (also) removing the gmp directory

It's now (mostly) gone as per your suggestion. See SPKG.txt.

If the patches are applied from src/, they should be applied (i.e., be appliable) with -p1 for consistency.

Okay.

Hunk #1 succeeded at 70 with fuzz 2 (offset 1 line).

Fixed

spkg-install in whole needs some clean-up

I've done some clean-up.

We should also configure with --with-gmp="$SAGE_LOCAL" (or --with-gmp-prefix="$SAGE_LOCAL", haven't tested that yet).

Done.

Since Sage also ships and builds the Boehm GC, we could most probably delete even more.

I'm not touching this part, except to add a "To do" to the SPKG.txt file.

If this is merged, can we close #9493?


I took this spkg and the maxima spkg from #11966 and built Sage from scratch. It built successfully on the following systems:

  • sage.math
  • hawk (David Kirkby's OpenSolaris machine)
  • skynet machines eno, silius, taurus

Doctests passed on all of these except for silius, which has always had other issues.

This spkg by itself builds on an OS X Lion laptop, at which point sage --lisp seems to work, but other parts of the Sage build have problems.

I'm still in the middle of builds on other machines.

Changed 9 years ago by jhpalmieri

diff between previous version and this one

comment:29 Changed 9 years ago by leif

Ok, delta patch looks sane (modulo some uppercase/lowercase inconsistency in SPKG.txt).

For most directories (except gmp), "Remove the contents of ..." should read "Remove the directory ..." (with rm -rf ...).


SomeoneTM should report the unconditional use of install-sh etc. from "optional" components' subdirectories upstream...

Also, there should be a way to force the use of a "system" Boehm GC (in our case, Sage's) on Darwin as well; haven't checked whether that changed in recent releases though. (We could open a follow-up for that, and submit a patch upstream in case this is still necessary.)

comment:30 Changed 9 years ago by jhpalmieri

Okay, here are the new diffs:

  • SPKG.txt

    diff --git a/SPKG.txt b/SPKG.txt
    a b Website: http://ecls.sourceforge.net/ 
    4141 * Note: deleting the following directories saves space: without doing
    4242   this, the spkg can grow from under 2.5 megabytes to almost 7
    4343   megabytes.
    44  * Delete the contents of the src/msvc directory
    45  * Delete the contents of the src/src/gc_unstable/ directory
    46  * Delete the contents of the src/src/libffi/ directory
    47  * Delete most of the contents of the src/src/gmp directory:
     44 * Remove the directory src/msvc/
     45 * Remove the directory src/src/gc_unstable/
     46 * Remove the directory src/src/libffi/
     47 * Remove most of the contents of the src/src/gmp directory:
    4848   everything except install.sh, config.*, and configfsf.*
    4949 * Build with --enable-unicode=no, and hence it is safe to:
    50    - Delete the contents of the src/contrib/encodings directory
    51    - Delete the contents of the src/contrib/unicode directory
     50   - Remove the directory src/contrib/encodings/
     51   - Remove the directory src/contrib/unicode/
    5252   (Building with --enable-unicode=yes, the default in the latest ecl
    5353   source, leads to problems with some strings in the Sage-maxima-ecl
    5454   interface.)
    Website: http://ecls.sourceforge.net/ 
    6363
    6464== Changelog ==
    6565
    66 === ecl-11.1.2.git.20111030.p0 (John H. Palmieri, 2 Novemer 2011) ===
     66=== ecl-11.1.2.git.20111030.p0 (John H. Palmieri, 4 November 2011) ===
    6767  * Trac #11884.  General clean-up: remove unneeded patches,
    6868    remove some source files (as described above in "Special
    6969    Update/Build Instructions"), echo error messages to stderr, etc.

I would also like to register a complaint that while in the src directory, running ./configure --help actually creates a directory (build) and then prints the message "Configuration complete. To build ECL, issue make in this directory." I wouldn't expect ./configure --help to actually do anything beyond print a message.

Changed 9 years ago by jhpalmieri

patch for ecl spkg; for review only

comment:31 Changed 9 years ago by jhpalmieri

Oh, and now I just changed some instances of "ecl" to "ECL" in SPKG.txt. The posted delta patch is out of date. Add to them the diffs from my previous message and also these lower/uppercase changes.

comment:32 Changed 9 years ago by jdemeyer

  • Priority changed from major to blocker

comment:33 Changed 9 years ago by jdemeyer

  • Status changed from needs_review to needs_work

This fails on OS X 10.4 PPC, see attached log file.

Changed 9 years ago by jdemeyer

Build failure on OS X 10.4 PPC

comment:34 Changed 9 years ago by jdemeyer

The last part of the log file is

;;; Note:
;;;   Invoking external command:
;;;   gcc -I. -I/Users/jdemeyer/sage-4.8.alpha2/spkg/build/ecl-11.1.2.git.20111030.p0/src/build/ -DECL_API -I/Users/jdemeyer/sage-4.8.alph
;;; Finished compiling EXT:BYTECMP;BYTECMP.LSP.
;;;
;;; Note:
;;;   Library initialization function is main_lib_LSP
;;; Note:
;;;   Invoking external command:
;;;   gcc -I. -I/Users/jdemeyer/sage-4.8.alpha2/spkg/build/ecl-11.1.2.git.20111030.p0/src/build/ -DECL_API -I/Users/jdemeyer/sage-4.8.alph
;;; Note:
;;;   Invoking external command:
;;;   ar cr liblsp.a eclinit8Mq5nn.o lsp/export.o lsp/defmacro.o lsp/helpfile.o lsp/evalmacros.o lsp/setf.o lsp/predlib.o lsp/seq.o lsp/ar
;;; Note:
;;;   Invoking external command:
;;;   ranlib liblsp.a
NIL
/usr/bin/libtool: file: liblsp.a(eClDaTa20110719) is not an object file (not allowed in a library)
/usr/bin/libtool: archive: liblsp.a truncated or malformed (archive header of next member extends past the end of the file)
;;; Note:
;;;   Invoking external command:
;;;   gcc -o libecl.dylib -L/Users/jdemeyer/sage-4.8.alpha2/spkg/build/ecl-11.1.2.git.20111030.p0/src/build/ c/main.o c/all_symbols2.o lib
Condition of type: SIMPLE-ERROR
Error code 1 when executing
(RUN-PROGRAM "gcc" ("-o" "libecl.dylib" "-L/Users/jdemeyer/sage-4.8.alpha2/spkg/build/ecl-11.1.2.git.20111030.p0/src/build/" "c/main.o" "c

Available restarts:

1. (CONTINUE) Continues anyway.

Top level.
>

At this point I got an interactive prompt(!). This prompt probably should be avoided anyway, by redirecting stdin from /dev/null during the build.

comment:35 Changed 9 years ago by jhpalmieri

This prompt probably should be avoided anyway, by redirecting stdin from /dev/null during the build.

Do you mean

  • spkg-install

    diff --git a/spkg-install b/spkg-install
    a b fi 
    105105# Before running make we touch build/TAGS so its building process is never triggered
    106106touch build/TAGS
    107107
    108 $MAKE
     108$MAKE < /dev/null
    109109if [ $? -ne 0 ]; then
    110110   echo >&2 "Error - Failed to build ECL ... exiting"
    111111   exit 1

I don't have access to an OS X 10.4 PPC machine (as far as I know), so it's going to be hard for me to test this.

comment:36 follow-up: Changed 9 years ago by was

I think we should consider ending support for 10.4 in Sage-5.0 (where we'll surely fully support 10.7). OS X 10.4 is from 2005, and it hasn't had security updates in since mid-2009.

comment:37 in reply to: ↑ 36 Changed 9 years ago by kcrisman

Replying to was:

I think we should consider ending support for 10.4 in Sage-5.0 (where we'll surely fully support 10.7). OS X 10.4 is from 2005, and it hasn't had security updates in since mid-2009.

Could be worth asking Harald how many downloads there have been of this. There seems to be a steady trickle of folks using this. At the same time, I understand the sentiment. Though see this amusing quote from TenFourFox's website:

 But we were horrified when Mozilla delivered the one-two punch of dropping 
both support for Tiger and our beloved Power Macs from Firefox. A quad 2.5GHz G5 
isn't worth using to surf the web? Really? And you guys still support Windows XP?

comment:38 Changed 9 years ago by jdemeyer

I would say: as long as it's easily doable to support OS X 10.4, let's do it. If some day, Sage needs a compelling feature from recent OS X, I wouldn't mind dropping support for older OS X versions.

comment:39 Changed 9 years ago by jdemeyer

Just figured out what happens (not why nor how to fix it):

The upstream ECL building script creates a library liblsp.a using the system's ar and ranlib tools. Then the script manually appends 24 bytes to the .a file. Then libtool trips over these extra bytes.

So the problem is certainly upstream.

comment:40 Changed 9 years ago by jdemeyer

The upstream problem on OS X 10.4 seems to have been introduced recently so going back to some earlier version might solve it. I will make a new spkg.

comment:41 Changed 9 years ago by jdemeyer

  • Status changed from needs_work to needs_review

New spkg which builds on OS X 10.4: http://boxen.math.washington.edu/home/jdemeyer/spkg/ecl-11.1.2.cvs20111107.p0.spkg

Please test this on OS X 10.7, I have no such machine.

comment:42 Changed 9 years ago by jdemeyer

  • Description modified (diff)
  • Report Upstream changed from N/A to Reported upstream. Little or no feedback.

comment:43 Changed 9 years ago by jdemeyer

  • Report Upstream changed from Reported upstream. Little or no feedback. to Fixed upstream, but not in a stable release.

5 hours, impressive...

comment:44 Changed 9 years ago by jdemeyer

  • Authors changed from William Stein, John Palmieri to William Stein, John Palmieri, Jeroen Demeyer
  • Description modified (diff)

comment:45 Changed 9 years ago by jhpalmieri

The spkg ecl-11.1.2.cvs20111107.p0.spkg doesn't build for me on OS X 10.7. Log file: http://sage.math.washington.edu/home/palmieri/misc/ecl-11.1.2.cvs20111107.p0.log.

The spkg ecl-11.1.2.cvs20111115.p0.spkg does build, and sage --lisp starts up and does a simple calculation (about all that I'm capable of in lisp these days). After that, sage -f maxima-... works (with the maxima spkg from #11966).

comment:46 Changed 9 years ago by jdemeyer

  • Description modified (diff)

comment:47 Changed 9 years ago by jdemeyer

  • Description modified (diff)

comment:48 follow-up: Changed 9 years ago by jhpalmieri

The spkg looks good to me except that you haven't committed your changes.

comment:49 Changed 9 years ago by kcrisman

  • Reviewers changed from Leif Leonhardy to Leif Leonhardy, John Palmieri

I can confirm that sage -ecl gives 4 when I enter (+ 2 2) on OS X PPC with this spkg. Amazing sleuthing...

comment:50 Changed 9 years ago by kcrisman

Did anyone try this and then the new Maxima spkg at #11966 on OS X 10.4 PPC? There is an error with the Maxima that looks nearly identical to the message on this one, about the archive header extending...

Changed 9 years ago by jdemeyer

Diff between ecl-11.1.2.git.20111030.p0.spkg and ecl-11.1.2.cvs20111115.p0.spkg

comment:51 in reply to: ↑ 48 Changed 9 years ago by jdemeyer

Replying to jhpalmieri:

The spkg looks good to me except that you haven't committed your changes.

I wanted to make sure it actually worked on OS X Lion. I committed now, does the spkg get a positive review then?

comment:52 Changed 9 years ago by jhpalmieri

What about kcrisman's comment about maxima not working on OS X 10.4 PPC? Otherwise, I'm ready to give this a positive review.

comment:53 Changed 9 years ago by kcrisman

I've tried all four combinations.

Works:

  • Old ECL + Old Maxima

Doesn't build, error as noted on #11996:

  • New ECL + New Maxima

Builds Maxima but doesn't create the library version properly:

  • New ECL + Old Maxima

Currently trying, but seems pointless:

  • Old ECL + New Maxima

comment:54 Changed 9 years ago by jdemeyer

I can confirm kcrisman's findings. With the ECL package from 2011-11-07 (which unfortunately does not work on OS X 10.7), Maxima builds properly.

comment:55 follow-ups: Changed 9 years ago by jhpalmieri

So what should we do? How hard is it to identify the differences between the two packages (2011-11-07 and 2011-11-15)? Then we could turn those differences into patches, and either build the earlier package on all platforms except Lion and apply the patches to build on Lion, or else apply the patches on all platforms except OS X 10.4 PPC.

(If this sounds like a good idea, I can't help much: I know nothing about git, and I also don't have a lot of time to work on this right now.)

comment:56 in reply to: ↑ 55 Changed 9 years ago by jdemeyer

  • Report Upstream changed from Fixed upstream, but not in a stable release. to Not yet reported upstream; Will do shortly.
  • Status changed from needs_review to needs_work

Replying to jhpalmieri:

So what should we do? How hard is it to identify the differences between the two packages (2011-11-07 and 2011-11-15)?

Unfortunately, a lot changed those days. It seems these changed made ECL work on OS X 10.7.

The best thing to do is probably to report this upstream, I will look into it.

comment:57 in reply to: ↑ 55 Changed 9 years ago by jdemeyer

Replying to jhpalmieri:

So what should we do? How hard is it to identify the differences between the two packages (2011-11-07 and 2011-11-15)? Then we could turn those differences into patches.

It's hard to believe, but the diff between today and 2011-11-07 is 846KB(!).

comment:58 Changed 9 years ago by jdemeyer

  • Report Upstream changed from Not yet reported upstream; Will do shortly. to Reported upstream. Little or no feedback.

comment:59 Changed 9 years ago by jdemeyer

  • Description modified (diff)

comment:60 Changed 9 years ago by jdemeyer

  • Report Upstream changed from Reported upstream. Little or no feedback. to Fixed upstream, but not in a stable release.

comment:61 Changed 9 years ago by jhpalmieri

This builds on OS X 10.6, OS X 10.7, and on sage.math: on these systems, I built the spkg and then maxima on top of it, and both sage --lisp and sage --maxima appear to work. On sage.math, I've also built from scratch successfully. I'm building from scratch on OS X 10.7, but that will take a while to complete.

I have no access to an OS X 10.4 machine, so I can't test there.

comment:62 follow-up: Changed 9 years ago by jhpalmieri

By the way, why did you delete this entry in the change log?

Add file spkg-make to re-create the src/ tree using CVS.

I thought it was useful.

comment:63 in reply to: ↑ 62 Changed 9 years ago by jdemeyer

  • Description modified (diff)

Replying to jhpalmieri:

By the way, why did you delete this entry in the change log?

Add file spkg-make to re-create the src/ tree using CVS.

I thought it was useful.

That was by mistake, corrected now.

I am testing on OS X 10.4 PPC now.

comment:64 Changed 9 years ago by jdemeyer

  • Description modified (diff)
  • Merged in set to sage-4.8.alpha3
  • Resolution set to fixed
  • Status changed from needs_work to closed

Seems to work on all OS X systems, and Maxima also, so positive_review.

comment:65 follow-up: Changed 9 years ago by dimpase

I can confirm that it also builds on Cygwin 1.7.9.

comment:66 in reply to: ↑ 65 Changed 9 years ago by kcrisman

I can confirm that it also builds on Cygwin 1.7.9.

Tentatively setting #11260 to sage-invalid, then.

comment:67 Changed 9 years ago by jdemeyer

  • Authors changed from William Stein, John Palmieri, Jeroen Demeyer to Dmitrii Pasechnik, Mike Hansen, Karl-Dieter Crisman, William Stein, John Palmieri, Jeroen Demeyer

comment:68 Changed 9 years ago by jdemeyer

  • Reviewers changed from Leif Leonhardy, John Palmieri to Karl-Dieter Crisman, Reg Burgess, François Bissey, Leif Leonhardy, John Palmieri

comment:69 Changed 9 years ago by jdemeyer

  • Description modified (diff)
Note: See TracTickets for help on using tickets.