ECL 9.8.4 fails to build in 64-bit mode, OS X 10.5.8, Sage 4.1.2.alpha0
Minh Nguyen
new ECL package ecl-9.8.4.spkg fails to build. The configure script of
ECL searches for an installation of the GMP library, but fails to find
one so it aborts the configuration. ECL failing to build means that
Maxima can't start compiling. This is rather strange because as I
reported on ticket #6564
http://trac.sagemath.org/sage_trac/ticket/6564#comment:21
the updated ECL spkg compiled OK on the same platform under Sage
4.1.1. So something else must have been messed up. This is now ticket
#6883
http://trac.sagemath.org/sage_trac/ticket/6883
--
Regards
Minh Van Nguyen
Dr. David Kirkby
That's my fault.
I made a change to the .spkg, which must have been after you committed
it. It is that which probably has the problem. I am just going to build
it on bsd.math now and check it. Sorry about that.
I believe the problem is that I omitted to export LDFLAGS, but I am
testing it now.
Did you set SAGE64=yes on bsd.math when you did this? If so, I'll do
likewise when I check it.
Dave
Minh Nguyen
On Fri, Sep 4, 2009 at 7:26 PM, Dr. David Kirkby<david....@onetel.net> wrote:
<SNIP>
> Did you set SAGE64=yes on bsd.math when you did this? If so, I'll do
> likewise when I check it.
Yes, I did that when trying to build Sage 4.1.2.alpha0 in 64-bit mode.
But I think it's not enough to set that environment variable to "yes";
one also needs to export it so that it would be picked up by
/usr/bin/evn
Before building Sage from source on Mac OS X 10.5.8 in 64-bit mode, I would do
export SAGE64=yes
and then issue "make". The default is to build in 32-bit mode. I have
successfully done so. Looking through the install.log file for a
32-bit build of Sage 4.1.2.alpha0, I see these lines:
checking for library containing strerror... none required
checking for __gmpz_init in -lgmp... yes
But the corresponding log file for a 64-bit build shows
checking for library containing strerror... none required
checking for __gmpz_init in -lgmp... no
configure: error: System gmp library requested but not found.
Failed to configure ECL ... exiting
So in the 32-bit case, ECL claims to have successfully detected the
necessary GMP library. But in the 64-bit case, it can't find that
library.
Dr. David Kirkby
Dr. David Kirkby
> So in the 32-bit case, ECL claims to have successfully detected the
> necessary GMP library. But in the 64-bit case, it can't find that
> library.
>
Even a 32-bit build would not build on bsd for me. I don't know whether
there is anything important in your path, since I notice you have your
own $HOME/usr/bin prepended to the system path, so anything in there
would be picked up first. I've just copied over some of your settings.
I'm now trying a 32 and 64-bit build with some settings you have.
Dave
Minh Nguyen
On Fri, Sep 4, 2009 at 8:35 PM, Dr. David Kirkby<david....@onetel.net> wrote:
<SNIP>
> Even a 32-bit build would not build on bsd for me. I don't know whether
> there is anything important in your path, since I notice you have your
> own $HOME/usr/bin prepended to the system path, so anything in there
>
> would be picked up first. I've just copied over some of your settings.
I compiled GNU coreutils-7.4 under my home directory on bsd.math and
installed the binaries in $HOME/usr/bin. I pre-pend $HOME/usr/bin to
my PATH variable so that I would run GNU versions of, e.g. ls, cp, mv,
etc. Here's my PATH:
[mvngu@bsd ~]$ echo $PATH
/Users/mvngu/usr:/Users/mvngu/usr/bin:/bin:/sbin:/usr/bin:/usr/sbin:/sw/bin:/usr/local/bin:/usr/texbin
Dr. David Kirkby
Thank you. I set up your path
echo $PATH
/Users/mvngu/usr:/Users/mvngu/usr/bin:/bin:/sbin:/usr/bin:/usr/sbin:/sw/bin:/usr/local/bin:/usr/texbin
[kirkby@bsd sage-4.1.2.alpha0]$ pwd
/Users/kirkby/64/sage-4.1.2.alpha0
but get an error installing 'R', so I don't even get as far as ECL.
Any ideas?
checking for long double... yes
checking size of long double... 16
checking for size_t... (cached) yes
checking size of size_t... 8
checking whether we can compute C Make dependencies... yes, using gcc
-std=gnu99 -MM
checking whether gcc -std=gnu99 supports -c -o FILE.lo... yes
checking how to get verbose linking output from sage_fortran...
configure: WARNING: cannot determine how to obtain linking information
from sage_fortran
checking for Fortran 77 libraries of sage_fortran...
checking how to get verbose linking output from gcc -std=gnu99... rm:
cannot remove `conftest.dSYM': Is a directory
-v
checking for C libraries of gcc -std=gnu99... rm: cannot remove
`conftest.dSYM': Is a directory
-lcrt1.10.5.o -L/Users/kirkby/64/sage-4.1.2.alpha0/local/lib/
-L/usr/lib/i686-apple-darwin9/4.0.1
-L/Users/kirkby/64/sage-4.1.2.alpha0/local/lib
-L/usr/lib/gcc/i686-apple-darwin9/4.0.1/x86_64
-L/usr/lib/gcc/i686-apple-darwin9/4.0.1
-L/usr/lib/gcc/i686-apple-darwin9/4.0.1/../../../i686-apple-darwin9/4.0.1
-L/usr/lib/gcc/i686-apple-darwin9/4.0.1/../../.. -lgcc_s.10.5 -lSystem
checking for dummy main to link with Fortran 77 libraries... rm: cannot
remove `conftest.dSYM': Is a directory
none
checking for Fortran 77 name-mangling scheme... rm: cannot remove
`conftest.dSYM': Is a directory
unknown
configure: WARNING: unknown Fortran name-mangling scheme
checking whether sage_fortran appends underscores to external names...
unknown
configure: error: cannot use Fortran
Error configuring R.
real 0m42.823s
user 0m13.749s
sys 0m25.588s
sage: An error occurred while installing r-2.6.1.p23
Please email sage-devel http://groups.google.com/group/sage-devel
explaining the problem and send the relevant part of
of /Users/kirkby/64/sage-4.1.2.alpha0/install.log. Describe your
computer, operating system, etc.
If you want to try to fix the problem, yourself *don't* just cd to
/Users/kirkby/64/sage-4.1.2.alpha0/spkg/build/r-2.6.1.p23 and type 'make'.
Instead type "/Users/kirkby/64/sage-4.1.2.alpha0/sage -sh"
in order to set all environment variables correctly, then cd to
/Users/kirkby/64/sage-4.1.2.alpha0/spkg/build/r-2.6.1.p23
(When you are done debugging, you can type "exit" to leave the
subshell.)
make[1]: *** [installed/r-2.6.1.p23] Error 1
William Stein
>
> Minh Nguyen wrote:
>> Hi David,
>>
>> On Fri, Sep 4, 2009 at 8:35 PM, Dr. David Kirkby<david....@onetel.net> wrote:
>>
>> <SNIP>
>>
>>> Even a 32-bit build would not build on bsd for me. I don't know whether
>>> there is anything important in your path, since I notice you have your
>>> own $HOME/usr/bin prepended to the system path, so anything in there
>>>
>>> would be picked up first. I've just copied over some of your settings.
>>
>> I compiled GNU coreutils-7.4 under my home directory on bsd.math and
>> installed the binaries in $HOME/usr/bin. I pre-pend $HOME/usr/bin to
>> my PATH variable so that I would run GNU versions of, e.g. ls, cp, mv,
>> etc. Here's my PATH:
>>
>> [mvngu@bsd ~]$ echo $PATH
>> /Users/mvngu/usr:/Users/mvngu/usr/bin:/bin:/sbin:/usr/bin:/usr/sbin:/sw/bin:/usr/local/bin:/usr/texbin
>>
>
> Thank you. I set up your path
>
> echo $PATH
> /Users/mvngu/usr:/Users/mvngu/usr/bin:/bin:/sbin:/usr/bin:/usr/sbin:/sw/bin:/usr/local/bin:/usr/texbin
>
> [kirkby@bsd sage-4.1.2.alpha0]$ pwd
> /Users/kirkby/64/sage-4.1.2.alpha0
>
> but get an error installing 'R', so I don't even get as far as ECL.
>
> Any ideas?
William
William Stein
Associate Professor of Mathematics
University of Washington
http://wstein.org
Dr. David Kirkby
How do I do that? I did
$ rm spkg/installed/fortran-20071120.p5
$ make
The reinstall of fortran worked ok, but R still failed.
I created a new spkg for ecl
http://sage.math.washington.edu/home/kirkby/Solaris-fixes/ecl-9.8.4.p0/ecl-9.8.4.p0.spkg
but whilst it builds on Solaris and builds on 32-bit OS X, it still does
not (for me at least) build on OS X 64-bit. It gets past the point where
it failed for Minh before, so perhaps he can try it.
Perhaps my OS X environment is crewed up for 64-bit
Dave
William Stein
(1) Make double triple sure that you set SAGE64 to "yes":
export SAGE64="yes"
(2) Type
./sage -f fortran-20071120.p5
(3) Then do make:
make
William
>
>
> I created a new spkg for ecl
>
> http://sage.math.washington.edu/home/kirkby/Solaris-fixes/ecl-9.8.4.p0/ecl-9.8.4.p0.spkg
>
> but whilst it builds on Solaris and builds on 32-bit OS X, it still does
> not (for me at least) build on OS X 64-bit. It gets past the point where
> it failed for Minh before, so perhaps he can try it.
>
> Perhaps my OS X environment is crewed up for 64-bit
>
> Dave
>
> >
>
Dr. David Kirkby
> Hi David,
>
>
> <SNIP>
>
>> The above definitely did *NOT* reinstall the fortan spkg.
>>
>> (1) Make double triple sure that you set SAGE64 to "yes":
>>
>> export SAGE64="yes"
>>
>> (2) Type
>>
>> ./sage -f fortran-20071120.p5
>
> of Sage. Here is what I would do to build Sage 4.1.2.alpha0 on OS X
> 10.5.8 in 64-bit mode. First I woud cd to SAGE_ROOT and delete that
> Fortran package:
>
> rm spkg/standard/fortran-20071120.p5.spkg
>
> Then copy over Michael Abshoff's custom-built Fortran package to the
> standard packages repository. You can find this package at
>
> http://sage.math.washington.edu/home/mvngu/apps/fortran-OSX64-20090120.spkg
Yours and William instructions seem more than a little different!
It would seem sensible if this step needs to be done, that the package
is included, but only built on OSX 64. Or better still, we find out what
is special about it, and integrate the special bits in some way to the
standard package if that is possible.
Dave
Dr. David Kirkby
I added some information at trac #6883. I'm puzzled how you ever managed
to get this to build, as I can't, even after I corrected the error in
the .spkg, but also after using the exact same .spkg as I believe you
used before. Take a look at the ticket.
Dave
Minh Nguyen
On Sat, Sep 5, 2009 at 9:58 PM, Dr. David Kirkby<david....@onetel.net> wrote:
<SNIP>
> I added some information at trac #6883. I'm puzzled how you ever managed
> to get this to build, as I can't, even after I corrected the error in
> the .spkg, but also after using the exact same .spkg as I believe you
> used before. Take a look at the ticket.
I think the problem lies in the following line of the file spkg-intall:
./configure --prefix=$SAGE_LOCAL --with-system-gmp --enable-boehm=system
I replaced that line with
./configure --prefix=$SAGE_LOCAL
An updated spkg can be found at
http://sage.math.washington.edu/home/mvngu/release/spkg/standard/ecl-9.8.4.p0.spkg
and am now testing it under various platforms. The machines sage.math,
mod.math, and geom.math are all very busy at the moment. So I have had
problems compiling Sage from scratch on those machines; ATLAS
complains about errors while tuning itself. This is usually
symptomatic of a busy system.
William Stein
>
> Hi David,
>
> On Sat, Sep 5, 2009 at 9:58 PM, Dr. David Kirkby<david....@onetel.net> wrote:
>
> <SNIP>
>
>> I added some information at trac #6883. I'm puzzled how you ever managed
>> to get this to build, as I can't, even after I corrected the error in
>> the .spkg, but also after using the exact same .spkg as I believe you
>> used before. Take a look at the ticket.
>
> I think the problem lies in the following line of the file spkg-intall:
>
> ./configure --prefix=$SAGE_LOCAL --with-system-gmp --enable-boehm=system
>
> I replaced that line with
>
> ./configure --prefix=$SAGE_LOCAL
>
> An updated spkg can be found at
>
> http://sage.math.washington.edu/home/mvngu/release/spkg/standard/ecl-9.8.4.p0.spkg
>
> and am now testing it under various platforms. The machines sage.math,
> mod.math, and geom.math are all very busy at the moment.
I've remedied this hopefully on sage.math by killing all jobs of a
certain very new user who didn't know about how sage.math is used.
William
Dr. David Kirkby
> Hi David,
> I think the problem lies in the following line of the file spkg-intall:
>
> ./configure --prefix=$SAGE_LOCAL --with-system-gmp --enable-boehm=system
>
> I replaced that line with
>
> ./configure --prefix=$SAGE_LOCAL
>
> An updated spkg can be found at
>
> http://sage.math.washington.edu/home/mvngu/release/spkg/standard/ecl-9.8.4.p0.spkg
>
> and am now testing it under various platforms. The machines sage.math,
> mod.math, and geom.math are all very busy at the moment. So I have had
> problems compiling Sage from scratch on those machines; ATLAS
> complains about errors while tuning itself. This is usually
> symptomatic of a busy system.
>
I do not believe that is building a 64-bit version of ecl, as CFLAGS is
set to -m64, but it is not exported. As soon as one exports a CFLAGS
containing -m64, so it fails.
The fact ECL is an interpreter, probably means you can get away with
mixing a 32-bit interpreter with other bits being 64-bit, but it is not
a true 64-bit build.
Here's one I made, which is very similar to yours, but has a few other
bugs sorted out.
http://sage.math.washington.edu/home/kirkby/Solaris-fixes/ecl-9.8.4.p0-3rd-attempt/ecl-9.8.4.p0.spkg
Note that the line;
#export CFLAGS
if you uncomments that line, so it fails to build. It only adds -O2, -g
and -m64.
Dave
Dr. David Kirkby
I forgot, it adds -Wall too.
John H Palmieri
>
> <SNIP>
> An updated spkg can be found at
>
> and am now testing it under various platforms.
64-bit.
John
John H Palmieri
if I first execute
export MAKE='make -j2'
but it works if MAKE='make'. Here's the tail end of the installation
with MAKE='make -j2'; I think I get a similar error with 32-bit or 64-
bit, but this is from the 64-bit attempt:
cd c; make -j2
make[2]: warning: -jN forced in submake: disabling jobserver mode.
cat /Applications/sage_builds/sage-4.1.2.alpha0-64bit/spkg/build/
ecl-9.8.4.p0/src/src/c/symbols_list.h | \
sed -e 's%{\([A-Z ]*.*".*"\),[^,]*,[ ]*NULL,.*}%{\1,NULL}%g' \
-e 's%{\([A-Z ]*.*".*"\),[^,]*,[ ]*\([^,]*\),.*}%{\1,"\2"}%g' \
-e 's%{NULL.*%{NULL,NULL}};%' > /Applications/sage_builds/
sage-4.1.2.alpha0-64bit/spkg/build/ecl-9.8.4.p0/src/src/c/
symbols_list2.h
if test -f ../CROSS-DPP ; then ../CROSS-DPP /Applications/sage_builds/
sage-4.1.2.alpha0-64bit/spkg/build/ecl-9.8.4.p0/src/src/c/main.d
main.c ; else ./dpp /Applications/sage_builds/sage-4.1.2.alpha0-64bit/
spkg/build/ecl-9.8.4.p0/src/src/c/main.d main.c ; fi
/bin/sh: ./dpp: No such file or directory
make[2]: *** [main.c] Error 127
make[2]: *** Waiting for unfinished jobs....
make[1]: *** [libeclmin.a] Error 2
make: *** [all] Error 2
John
Minh Nguyen
<SNIP>
> Well, now it seems to have built on 64-bit as well. It doesn't work
> if I first execute
>
> export MAKE='make -j2'
>
> but it works if MAKE='make'.
I got the same error even if I set MAKE='make' and then issue make
again. Compilation went OK in 32-bit mode on bsd.math.
David Kirkby
>
>
>
> On Sep 6, 12:58 pm, John H Palmieri <jhpalmier...@gmail.com> wrote:
>> On Sep 5, 11:18 pm, Minh Nguyen <nguyenmi...@gmail.com> wrote:
>>
>> > Hi David,
>>
>> > On Sat, Sep 5, 2009 at 9:58 PM, Dr. David Kirkby<david.kir...@onetel.net> wrote:
>>
>> > <SNIP>
>>
>> > An updated spkg can be found at
>>
>> >http://sage.math.washington.edu/home/mvngu/release/spkg/standard/ecl-...
>>
>> > and am now testing it under various platforms.
>>
>> Using this, I can build successfully on Mac OS X 10.5, 32-bit, but not
>> 64-bit.
>
> Well, now it seems to have built on 64-bit as well. It doesn't work
> if I first execute
>
> export MAKE='make -j2'
>
> but it works if MAKE='make'. Here's the tail end of the installation
> with MAKE='make -j2'; I think I get a similar error with 32-bit or 64-
> bit, but this is from the 64-bit attempt:
>
John,
I'm not convinced that is building a 64-bit version. This is based on 2 things.
1) CFLAGS is set to -m64 in that .spkg, but not exported, so -m64 is
not added to the build compile line.
2) The main ECL developer has said on the ECL list that -m64 will
break it, but he added an ABI option which is only effective on OS X,
but will not hurt on other platforms. It is not however clear if that
ABI option is in ECL 9.8.4, or only in the CVS.
I tried setting ABI=64, and that fails, but I note there is a warning
that the only two values accepted for ABI are 'long' and 'longlong'. I
am going to suggest he permit 32 or 64 too, or if not, throw an error,
rather than a warning, if ABI is set to a non-standard value.
I tried setting the ABI to 'longlong', but I'm not convinced that is
making a 64-bit build, as I never see '-m64' on any compile line at
all. Also when I run
file ./local/lib/libecl.9.8.4.dylib
to see if it has created a 64-bit library, it does not appear to me at
has. It says:
./local/lib/libecl.9.8.4.dylib: Mach-O dynamically linked shared library i386
whereas for other libraries 'file' reports:
./local/lib/libzn_poly.dylib: Mach-O 64-bit dynamically
linked shared library x86_64
I'd be intersted what you get if you run 'file' on the library. I
believe you will find you are generating a 32-bit library, not the
64-bit you think you are.
I've created another .spkg file, which fixes some issues in the
previous ones posted. It also unsets 'make' so you should find a
parallel build will not break ECL, as it ignores the '-j2' now.
The new .spkg can be found here:
http://sage.math.washington.edu/home/kirkby/Solaris-fixes/ecl-9.8.4.p0-5th-attempt/ecl-9.8.4.p0.spkg
but note it is not building a 64-bit version properly. I've set the
ABI to 'longlong' but it is NOT making a 64-bit library.
I do not know if
* One is supposed to add -m64 and set ABI to longlong.
* Whether the ABI code is actually present in the version of ECL we are using.
Whatever we need to build a 64-bit library on OS X, I don't think it
is as simple as just changing the configure line as in Minh's file. It
needs something else.
Dave
John H Palmieri
> 2009/9/6 John H Palmieri <jhpalmier...@gmail.com>:
> John,
> I'm not convinced that is building a 64-bit version. This is based on 2 things.
> Also when I run
>
> file ./local/lib/libecl.9.8.4.dylib
>
> to see if it has created a 64-bit library, it does not appear to me at
> has. It says:
>
> ./local/lib/libecl.9.8.4.dylib: Mach-O dynamically linked shared library i386
>
> whereas for other libraries 'file' reports:
>
> ./local/lib/libzn_poly.dylib: Mach-O 64-bit dynamically
> linked shared library x86_64
>
> I'd be intersted what you get if you run 'file' on the library. I
> believe you will find you are generating a 32-bit library, not the
> 64-bit you think you are.
Sage seems to run with it, though. Will it actually do something
wrong, or just not be as fast as a 64-bit library? (I'm running the
test suite now...)
John
Dan Drake
> Well, now it seems to have built on 64-bit as well. It doesn't work
> if I first execute
>
> export MAKE='make -j2'
>
> but it works if MAKE='make'. Here's the tail end of the installation
> with MAKE='make -j2'; I think I get a similar error with 32-bit or 64-
> bit, but this is from the 64-bit attempt:
I was using MAKE='make -j4' and got the same thing John got:
cd c; make -j4
make[2]: Entering directory `/var/tmp/sage-4.1.2.alpha1/spkg/build/ecl-9.8.4/src/build/c'
make[2]: warning: -jN forced in submake: disabling jobserver mode.
cat /var/tmp/sage-4.1.2.alpha1/spkg/build/ecl-9.8.4/src/src/c/symbols_list.h | \
sed -e 's%{\([A-Z ]*.*".*"\),[^,]*,[ ]*NULL,.*}%{\1,NULL}%g' \
-e 's%{\([A-Z ]*.*".*"\),[^,]*,[ ]*\([^,]*\),.*}%{\1,"\2"}%g' \
-e 's%{NULL.*%{NULL,NULL}};%' > /var/tmp/sage-4.1.2.alpha1/spkg/build/ecl-9.8.4/src/src/c/symbols_list2.h
if test -f ../CROSS-DPP ; then ../CROSS-DPP /var/tmp/sage-4.1.2.alpha1/spkg/build/ecl-9.8.4/src/src/c/main.d main.c ; else ./dpp /var/tmp/sage-4.1.2.alpha1/spkg/build/ecl-9.8.4/src/src/c/main.d main.c ; fi
/bin/sh: ./dpp: not found
if test -f ../CROSS-DPP ; then ../CROSS-DPP /var/tmp/sage-4.1.2.alpha1/spkg/build/ecl-9.8.4/src/src/c/symbol.d symbol.c ; else ./dpp /var/tmp/sage-4.1.2.alpha1/spkg/build/ecl-9.8.4/src/src/c/symbol.d symbol.c ; fi
/bin/sh: ./dpp: not found
make[2]: *** [main.c] Error 127
(This is Ubuntu 9.04 amd64 on a Core 2.) David Kirkby suggested that
when using regular MAKE=make, it's not really compiling a 64-bit binary,
but here on Linux, with MAKE=make, ECL compiles, and I get:
$ file libecl.so.9.8.4
libecl.so.9.8.4: ELF 64-bit LSB shared object, x86-64, version 1 (SYSV),
dynamically linked, not stripped
I did have a problem doctesting my build of 4.1.2.alpha1 -- some doctest
used up all the memory, and I had to kill everything -- and I'll try
again tonight to see if the doctest problem is repeatable and possibly
related to ECL.
Dan
--
--- Dan Drake
----- http://mathsci.kaist.ac.kr/~drake
-------
Juanjo
On Sep 8, 10:34 am, Dan Drake <dr...@kaist.edu> wrote:
> With 4.1.2.alpha1, I'm seeing the same error reported by John Palmieri:
>
> > Well, now it seems to have built on 64-bit as well. It doesn't work
> > if I first execute
>
> > export MAKE='make -j2'
bring you absolutely nothing, for most of the time is spent in a
sequential process which is compiling the lisp library.
Juanjo
David Kirkby
The previous spkg-install did unset MAKE, but I put a note there that
this might not be appropiate and removed that. I've noticed a lot of
things which seem to have been left over and not appropiate. This one
seems I was wrong.
I have already produced a package which has this unset again. I am
stuck at a railways station now, and don't have time to check it over,
but I will create a new .spkg which fixes that and some other issues
I'm aware of.
From what I understand, ecl is bascially an interpreter for maxima. In
which case, I suspect the fact it is 32-bit will have little effect
unless one wished to alloate a lot of memory. Most programs in Solaris
are compiled as 32-bit, despite this being a 64-bit OS. It is
generally faster, since as pointers are smaller, and so more can be
fitted into the cache. 64-bit code does have its disadvantages.
Dave
Juanjo
> From what I understand, ecl is bascially an interpreter for maxima. In
> which case, I suspect the fact it is 32-bit will have little effect
> unless one wished to alloate a lot of memory. Most programs in Solaris
> are compiled as 32-bit, despite this being a 64-bit OS. It is
> generally faster, since as pointers are smaller, and so more can be
> fitted into the cache. 64-bit code does have its disadvantages.
binaries. It is basically forbidden. So if you build Sage in 64-bits
mode, then ECL has to be built in 64-bits mode as well.
Juanjo
William Stein
That is only if we use ECL as a library, which Sage does _not_ do (yet).
Nils Bruin's recent work is a push toward doing that.
William
Minh Nguyen
As a shot in the dark, I tried compiling in 64-bit mode on OS X each
of David Kirkby's updated ECL packages at
http://sage.math.washington.edu/home/kirkby/Solaris-fixes/ecl-9.8.4.p0-2nd-attempt/
http://sage.math.washington.edu/home/kirkby/Solaris-fixes/ecl-9.8.4.p0-3rd-attempt/
http://sage.math.washington.edu/home/kirkby/Solaris-fixes/ecl-9.8.4.p0-4th-attempt/
http://sage.math.washington.edu/home/kirkby/Solaris-fixes/ecl-9.8.4.p0-5th-attempt/
For "ecl-9.8.4.p0-2nd-attempt" I set the LDFLAGS in the file
spkg-install as follows:
# Compile for 64-bit if SAGE64 is set to 'yes' or '1'
if [ "x$SAGE64" = "xyes" ] || [ "x$SAGE64" = "x1" ] ; then
echo "Building a 64-bit version of Sage"
CFLAGS="$CFLAGS -m64 "
CXXFLAGS="$CXXFLAGS -m64 "
FFLAGS="$FFLAGS -m64 "
FCFLAGS="$FCFLAGS -m64 "
F77FLAGS="$F77FLAGS -m64 "
if [ `uname` = "Darwin" ]; then
LDFLAGS="$LDFLAGS -m64"
fi
fi
For "ecl-9.8.4.p0-3rd-attempt" I set the LDFLAGS in the file
spkg-install as follows:
# Compile for 64-bit if SAGE64 is set to 'yes' or '1'
if [ "x$SAGE64" = "xyes" ] || [ "x$SAGE64" = "x1" ] ; then
echo "Building a 64-bit version of Sage"
CFLAGS="$CFLAGS -m64 "
CXXFLAGS="$CXXFLAGS -m64 "
FFLAGS="$FFLAGS -m64 "
FCFLAGS="$FCFLAGS -m64 "
F77FLAGS="$F77FLAGS -m64 "
if [ `uname` = "Darwin" ]; then
LDFLAGS="$LDFLAGS -m64"
fi
fi
For "ecl-9.8.4.p0-4th-attempt":
# Compile for 64-bit if SAGE64 is set to 'yes' or '1'
if [ "x$SAGE64" = "xyes" ] || [ "x$SAGE64" = "x1" ] ; then
echo "Building a 64-bit version of Sage"
if [ `uname` = "Darwin" ]; then
ABI=64
export ABI
LDFLAGS="$LDFLAGS -m64"
else
CFLAGS="$CFLAGS -m64 "
CXXFLAGS="$CXXFLAGS -m64 "
FCFLAGS="$FCFLAGS -m64 "
F77FLAGS="$F77FLAGS -m64 "
fi
fi
For "ecl-9.8.4.p0-5th-attempt":
# Compile for 64-bit if SAGE64 is set to 'yes' or '1'
if [ "x$SAGE64" = "xyes" ] || [ "x$SAGE64" = "x1" ] ; then
echo "Building a 64-bit version of Sage"
if [ `uname` = "Darwin" ]; then
ABI=longlong
export ABI
LDFLAGS="$LDFLAGS -m64"
else
CFLAGS="$CFLAGS -m64 "
CXXFLAGS="$CXXFLAGS -m64 "
FCFLAGS="$FCFLAGS -m64 "
F77FLAGS="$F77FLAGS -m64 "
fi
fi
With the LDFLAGS variable set as above, compilation failed in all
cases. An interesting thing is that they fail in different ways. For
"ecl-9.8.4.p0-2nd-attempt", the compilation aborted with the error
message:
if [ -f CROSS-COMPILER ]; then \
./CROSS-COMPILER compile; \
else \
ECLDIR=`pwd`/ ./ecl_min compile; \
fi
;*** Lisp core booted ****
ECL (Embeddable Common Lisp)
Internal or unrecoverable error in:
Lisp initialization error.
[2: No such file or directory]
/bin/sh: line 1: 79376 Abort trap ECLDIR=`pwd`/ ./ecl_min compile
make[3]: *** [bin/ecl] Error 134
make[2]: *** [all] Error 2
For "ecl-9.8.4.p0-3rd-attempt", "ecl-9.8.4.p0-4th-attempt", and
"ecl-9.8.4.p0-5th-attempt" the compilation aborted with the error
message:
if [ -f CROSS-COMPILER ]; then \
touch ecl_min; \
else \
gcc -L/scratch/mvngu/sandbox-64/sage-4.1.2.alpha1/local/lib -m6\
4 -lffi -o ecl_min cinit.o c/all_symbols.o -L./ libeclmin.a -leclgc -lgmp -lm\
;\
fi
ld warning: in cinit.o, file is not of required architecture
ld warning: in c/all_symbols.o, file is not of required architecture
ld warning: in libeclmin.a, file is not of required architecture
ld warning: in .//libeclgc.a, file is not of required architecture
Undefined symbols:
"_main", referenced from:
start in crt1.10.5.o
ld: symbol(s) not found
collect2: ld returned 1 exit status
make[3]: *** [ecl_min] Error 1
make[2]: *** [all] Error 2
The full log is up at
http://sage.math.washington.edu/home/mvngu/doc/install/install-4.1.2.alpha1-bsd64-kirkby-ecl.log
Dr. David Kirkby
> Hi folks,
>
> As a shot in the dark, I tried compiling in 64-bit mode on OS X each
> of David Kirkby's updated ECL packages at
>
> http://sage.math.washington.edu/home/kirkby/Solaris-fixes/ecl-9.8.4.p0-2nd-attempt/
> http://sage.math.washington.edu/home/kirkby/Solaris-fixes/ecl-9.8.4.p0-3rd-attempt/
> http://sage.math.washington.edu/home/kirkby/Solaris-fixes/ecl-9.8.4.p0-4th-attempt/
> http://sage.math.washington.edu/home/kirkby/Solaris-fixes/ecl-9.8.4.p0-5th-attempt/
I think the basic issue is that version 9.8.4 of ECL will not build on
OS X 64-bit. It will need the version from CVS, but that is of course
not as well tested. I could make a package from the CVS version and try
that.
It would appear LDFLAGS does need to be set to -m64. Also, ABI needs to
be set to 64 for the current CVS version. I'll create one like that, and
see how it goes
dave
Dr. David Kirkby
> Hi folks,
>
> As a shot in the dark, I tried compiling in 64-bit mode on OS X each
> of David Kirkby's updated ECL packages at
>
> http://sage.math.washington.edu/home/kirkby/Solaris-fixes/ecl-9.8.4.p0-2nd-attempt/
> http://sage.math.washington.edu/home/kirkby/Solaris-fixes/ecl-9.8.4.p0-3rd-attempt/
> http://sage.math.washington.edu/home/kirkby/Solaris-fixes/ecl-9.8.4.p0-4th-attempt/
> http://sage.math.washington.edu/home/kirkby/Solaris-fixes/ecl-9.8.4.p0-5th-attempt/
>
Can you try:
That is taken from CVS on 13th-Sept-2009, and would appear for me at
least to build as 64-bit on OS X. Of course, there is some risk of this,
as Juanjo has not tested this as thoroughly as the stable release 9.8.4.
The .spkg will need a bit of minor tidying up, as SPKG.txt has not been
updated properly. But that aside, I'd be interested if it builds on
different platforms.