sagemath / sage

Main repository of SageMath
https://www.sagemath.org
Other
1.43k stars 479 forks source link

Fix ECL so it builds on OS X Lion #11884

Closed jhpalmieri closed 12 years ago

jhpalmieri commented 13 years ago

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.

Depends on #11966

Upstream: Fixed upstream, but not in a stable release.

CC: @mwhansen @nexttime

Component: packages: standard

Keywords: ecl spkg upgrade update lion darwin 11

Author: Dmitrii Pasechnik, Mike Hansen, Karl-Dieter Crisman, William Stein, John Palmieri, Jeroen Demeyer

Reviewer: Karl-Dieter Crisman, Reg Burgess, François Bissey, Leif Leonhardy, John Palmieri

Merged: sage-4.8.alpha3

Issue created by migration from https://trac.sagemath.org/ticket/11884

jhpalmieri commented 13 years ago
comment:1

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.)

jhpalmieri commented 13 years ago
comment:2

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?

jhpalmieri commented 13 years ago
comment:3

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

83660e46-0051-498b-a8c1-f7a7bd232b5a commented 13 years ago

Changed keywords from ecl lion to ecl spkg upgrade update lion darwin 11

kcrisman commented 13 years ago
comment:5

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.

kcrisman commented 13 years ago
comment:6

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

kcrisman commented 13 years ago
comment:7

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.

kcrisman commented 13 years ago

Description changed:

--- 
+++ 
@@ -1 +1,3 @@
 As the summary says.
+
+The home base for this ticket is the Lion ticket #11881.
williamstein commented 13 years ago
comment:9

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.
williamstein commented 13 years ago

Description changed:

--- 
+++ 
@@ -1,3 +1,8 @@
 As the summary says.

 The home base for this ticket is the Lion ticket #11881.
+
+  
+There are no claims that this fixes Maxima building; the only claim is that this new package builds and ecl runs standalone. 
+
+Package: http://sage.math.washington.edu/home/wstein/patches/ecl-11.1.2.git.20111030.spkg
williamstein commented 13 years ago
comment:10

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
williamstein commented 13 years ago
comment:11

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

}}}

williamstein commented 13 years ago

Description changed:

--- 
+++ 
@@ -3,6 +3,6 @@
 The home base for this ticket is the Lion ticket #11881.

-There are no claims that this fixes Maxima building; the only claim is that this new package builds and ecl runs standalone. 
+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. 

 Package: http://sage.math.washington.edu/home/wstein/patches/ecl-11.1.2.git.20111030.spkg
kcrisman commented 13 years ago
comment:13

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

kcrisman commented 13 years ago
comment:14

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.

83660e46-0051-498b-a8c1-f7a7bd232b5a commented 13 years ago

Reviewer: Leif Leonhardy

83660e46-0051-498b-a8c1-f7a7bd232b5a commented 13 years ago
comment:15
== 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/

83660e46-0051-498b-a8c1-f7a7bd232b5a commented 13 years ago

Author: William Stein

83660e46-0051-498b-a8c1-f7a7bd232b5a commented 13 years ago
comment:16

Replying to @nexttime:

== 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
83660e46-0051-498b-a8c1-f7a7bd232b5a commented 13 years ago
comment:17

Replying to @nexttime:

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
...
jhpalmieri commented 13 years ago
comment:18

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

jhpalmieri commented 13 years ago
comment:19

Replying to @nexttime:

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.

jhpalmieri commented 13 years ago

Description changed:

--- 
+++ 
@@ -5,4 +5,4 @@

 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. 

-Package: http://sage.math.washington.edu/home/wstein/patches/ecl-11.1.2.git.20111030.spkg
+Package: [http://sage.math.washington.edu/home/palmieri/SPKG/ecl-11.1.2.git.20111030.p0.spkg](http://sage.math.washington.edu/home/palmieri/SPKG/ecl-11.1.2.git.20111030.p0.spkg)
jhpalmieri commented 13 years ago
comment:20

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

jhpalmieri commented 13 years ago
comment:21

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?)

jhpalmieri commented 13 years ago

Dependencies: #11966

jhpalmieri commented 13 years ago
comment:22

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).

jhpalmieri commented 13 years ago
comment:23

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.

jhpalmieri commented 13 years ago
comment:24

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

diff --git a/SPKG.txt b/SPKG.txt
--- a/SPKG.txt
+++ b/SPKG.txt
@@ -51,10 +51,13 @@ Website: http://ecls.sourceforge.net/
 == Changelog ==

 === ecl-11.1.2.git.20111030.p0 (John H. Palmieri, 2 Novemer 2011) ===
-  * Trac #11884: general clean-up: remove unneeded patches,
+  * Trac #11884.  General clean-up: remove unneeded patches,
     remove some source files (as described above in "Special
-    Update/Build Instructions").  Also check the error code when
-    running 'patch' in spkg-install.
+    Update/Build Instructions").
+  * Check the error code when running 'patch' in spkg-install.
+  * Run configure with the option "--enable-unicode=no" -- this was
+    the default in previous versions of ecl, and using the new default
+    of "yes" causes problems with some strings.

 === ecl-11.1.2.git.20111030 (William Stein, 30th October 2011) ===
   * Upgraded for trac 11884.   I got this by using
diff --git a/spkg-install b/spkg-install
--- a/spkg-install
+++ b/spkg-install
@@ -90,9 +90,9 @@ if [ "x`uname -sm`" = "xSunOS i86pc" ] &
    # 1) Solaris, Solaris Express or OpenSolaris (SunOS) 
    # 2) Intel or AMD CPU 
    # 3) 64-bit build
-   ./configure --prefix="$SAGE_LOCAL" --with-dffi=no
+   ./configure --prefix="$SAGE_LOCAL" --with-unicode=no --with-dffi=no
 else
-   ./configure --prefix="$SAGE_LOCAL" 
+   ./configure --prefix="$SAGE_LOCAL" --with-unicode=no
 fi

 if [ $? -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...

jhpalmieri commented 13 years ago
comment:25

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

83660e46-0051-498b-a8c1-f7a7bd232b5a commented 13 years ago
comment:26

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.

83660e46-0051-498b-a8c1-f7a7bd232b5a commented 13 years ago
comment:27

Replying to @nexttime:

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.

jhpalmieri commented 13 years ago
comment:28

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:

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.

jhpalmieri commented 13 years ago

Changed author from William Stein to William Stein, John Palmieri

jhpalmieri commented 13 years ago

diff between previous version and this one

83660e46-0051-498b-a8c1-f7a7bd232b5a commented 13 years ago
comment:29

Attachment: trac_11884-ecl.delta.patch.gz

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.)

jhpalmieri commented 13 years ago
comment:30

Okay, here are the new diffs:

diff --git a/SPKG.txt b/SPKG.txt
--- a/SPKG.txt
+++ b/SPKG.txt
@@ -41,14 +41,14 @@ Website: http://ecls.sourceforge.net/
  * Note: deleting the following directories saves space: without doing
    this, the spkg can grow from under 2.5 megabytes to almost 7
    megabytes.
- * Delete the contents of the src/msvc directory
- * Delete the contents of the src/src/gc_unstable/ directory
- * Delete the contents of the src/src/libffi/ directory
- * Delete most of the contents of the src/src/gmp directory:
+ * Remove the directory src/msvc/
+ * Remove the directory src/src/gc_unstable/
+ * Remove the directory src/src/libffi/
+ * Remove most of the contents of the src/src/gmp directory:
    everything except install.sh, config.*, and configfsf.*
  * Build with --enable-unicode=no, and hence it is safe to:
-   - Delete the contents of the src/contrib/encodings directory
-   - Delete the contents of the src/contrib/unicode directory
+   - Remove the directory src/contrib/encodings/
+   - Remove the directory src/contrib/unicode/
    (Building with --enable-unicode=yes, the default in the latest ecl
    source, leads to problems with some strings in the Sage-maxima-ecl
    interface.)
@@ -63,7 +63,7 @@ Website: http://ecls.sourceforge.net/

 == Changelog ==

-=== ecl-11.1.2.git.20111030.p0 (John H. Palmieri, 2 Novemer 2011) ===
+=== ecl-11.1.2.git.20111030.p0 (John H. Palmieri, 4 November 2011) ===
   * Trac #11884.  General clean-up: remove unneeded patches,
     remove some source files (as described above in "Special
     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.

jhpalmieri commented 13 years ago

patch for ecl spkg; for review only

jhpalmieri commented 13 years ago
comment:31

Attachment: trac_11884-ecl.patch.gz

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.

jdemeyer commented 12 years ago
comment:33

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

jdemeyer commented 12 years ago

Attachment: ecl-11.1.2.git.20111030.p0.log

Build failure on OS X 10.4 PPC

jdemeyer commented 12 years ago
comment:34

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.

jhpalmieri commented 12 years ago
comment:35

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

Do you mean

diff --git a/spkg-install b/spkg-install
--- a/spkg-install
+++ b/spkg-install
@@ -105,7 +105,7 @@ fi
 # Before running make we touch build/TAGS so its building process is never triggered
 touch build/TAGS

-$MAKE
+$MAKE < /dev/null
 if [ $? -ne 0 ]; then
    echo >&2 "Error - Failed to build ECL ... exiting"
    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.

williamstein commented 12 years ago
comment:36

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.

kcrisman commented 12 years ago
comment:37

Replying to @williamstein:

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?
jdemeyer commented 12 years ago
comment:38

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.

jdemeyer commented 12 years ago
comment:39

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.

jdemeyer commented 12 years ago
comment:40

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.

jdemeyer commented 12 years ago
comment:41

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.

jdemeyer commented 12 years ago

Description changed:

--- 
+++ 
@@ -2,7 +2,10 @@

 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. 
+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.

-Package: [http://sage.math.washington.edu/home/palmieri/SPKG/ecl-11.1.2.git.20111030.p0.spkg](http://sage.math.washington.edu/home/palmieri/SPKG/ecl-11.1.2.git.20111030.p0.spkg)
+Package (broken on OS X 10.4 PPC): [http://sage.math.washington.edu/home/palmieri/SPKG/ecl-11.1.2.git.20111030.p0.spkg](http://sage.math.washington.edu/home/palmieri/SPKG/ecl-11.1.2.git.20111030.p0.spkg)
+
+Alternative package (works on OS X 10.4 PPC): [http://boxen.math.washington.edu/home/jdemeyer/spkg/ecl-11.1.2.cvs20111107.p0.spkg](http://boxen.math.washington.edu/home/jdemeyer/spkg/ecl-11.1.2.cvs20111107.p0.spkg)
+
+The most recent CVS version fails on OS X 10.4 PPC, [reported upstream](http://sourceforge.net/tracker/?func=detail&aid=3437863&group_id=30035&atid=398053).