Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[with spkg's] port Sage to OS X 10.6 #6849

Closed
williamstein opened this issue Aug 31, 2009 · 23 comments
Closed

[with spkg's] port Sage to OS X 10.6 #6849

williamstein opened this issue Aug 31, 2009 · 23 comments

Comments

@williamstein
Copy link
Contributor

Attach to this ticket some of the fixes for getting Sage to build on OS X 10.6 (the new release of OS X).

Note that a Sage build on OS X 10.5 does seem to work fine on 10.6, but Sage does not "just build" on 10.6.

  1. We upgrade readline to 6.0, since 5.2 doesn't build on OS X 10.6:

    http://sage.math.washington.edu/home/wstein/tmp/readline-6.0.spkg

or

http://sage.math.washington.edu/home/kirkby/Solaris-fixes/readline-6.0/readline-6.0.spkg

This new spkg needs to be reviewed and build tested on Linux and OS X 10.4. (I tested it on 10.5.)

CC: @craigcitro @sagetrac-drkirkby

Component: porting

Author: William Stein

Reviewer: John Palmieri, Minh Van Nguyen

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

@williamstein williamstein added this to the sage-4.2 milestone Aug 31, 2009
@williamstein

This comment has been minimized.

@williamstein
Copy link
Contributor Author

comment:2

After readline, the next problem is that R fails to build (at least in 64-bit mode):

darwin8/4.2.3/x86_64 -L/Users/wstein/build/sage-4.1.1/local/lib/gcc/i686-apple-darwin8/4.2.3 -L/Users/wstein/build/sage-4.1.1/local/lib/gcc -L/usr/local/lib -lgfortran -lgcc_s.10.4  ../extra/zlib/libz.a ../extr
a/bzip2/libbz2.a ../extra/pcre/libpcre.a  ../extra/intl/libintl.a -liconv  -Wl,-framework -Wl,CoreFoundat
ion -lreadline  -lm
ld: symbol dyld_stub_binding_helper not defined (usually in crt1.o/dylib1.o/bundle1.o)
collect2: ld returned 1 exit status
make[5]: *** [libR.dylib] Error 1make[4]: *** [R] Error 2
make[3]: *** [R] Error 1
make[2]: *** [R] Error 1
Error building R.

real    2m52.365s
user    2m45.681s
sys     0m56.183ssage: An error occurred while installing r-2.6.1.p23

@williamstein
Copy link
Contributor Author

comment:3

Next failure is the Boehm GC:

 gcc -DPACKAGE_NAME=\"gc\" -DPACKAGE_TARNAME=\"gc\" -DPACKAGE_VERSION=\"7.1\" "-DPACKAGE_STRING=\"gc 7.1\"" -DPACKAGE_BUGREPORT=\"[email protected]\" -DGC_VERSION_MAJOR=7 -DGC_VERSION_MINOR=1 -DPACKAGE=\"gc\" -DVERSION=\"7.1\" -DGC_DARWIN_THREADS=1 -DTHREAD_LOCAL_ALLOC=1 -DHAS_X86_THREAD_STATE32___EAX=1 -DSTDC_HEA
DERS=1 -DHAVE_SYS_TYPES_H=1 -DHAVE_SYS_STAT_H=1 -DHAVE_STDLIB_H=1 -DHAVE_STRING_H=1 -DHAVE_MEMORY_H=1 -DH
AVE_STRINGS_H=1 -DHAVE_INTTYPES_H=1 -DHAVE_STDINT_H=1 -DHAVE_UNISTD_H=1 -DHAVE_DLFCN_H=1 -DNO_EXECUTE_PER
MISSION=1 -DALL_INTERIOR_POINTERS=1 -DGC_GCJ_SUPPORT=1 -DJAVA_FINALIZATION=1 -DATOMIC_UNCOLLECTABLE=1 -DL
ARGE_CONFIG=1 -I./include -fexceptions -I libatomic_ops/src -O2 -g -fPIC -m64 -MT atomic_ops.lo -MD -MP -
MF .deps/atomic_ops.Tpo -c atomic_ops.c  -fno-common -DPIC -o .libs/atomic_ops.o
In file included from mach_dep.c:163:
/usr/include/ucontext.h:42:2: error: #error ucontext routines are deprecated, and require _XOPEN_SOURCE t
o be defined
make[3]: *** [mach_dep.lo] Error 1
make[3]: *** Waiting for unfinished jobs....
 gcc -DPACKAGE_NAME=\"gc\" -DPACKAGE_TARNAME=\"gc\" -DPACKAGE_VERSION=\"7.1\" "-DPACKAGE_STRING=\"gc 7.1\
"" -DPACKAGE_BUGREPORT=\"[email protected]\" -DGC_VERSION_MAJOR=7 -DGC_VERSION_MINOR=1 -DPACKAGE=\"gc\" -
DVERSION=\"7.1\" -DGC_DARWIN_THREADS=1 -DTHREAD_LOCAL_ALLOC=1 -DHAS_X86_THREAD_STATE32___EAX=1 -DSTDC_HEA
DERS=1 -DHAVE_SYS_TYPES_H=1 -DHAVE_SYS_STAT_H=1 -DHAVE_STDLIB_H=1 -DHAVE_STRING_H=1 -DHAVE_MEMORY_H=1 -DH
AVE_STRINGS_H=1 -DHAVE_INTTYPES_H=1 -DHAVE_STDINT_H=1 -DHAVE_UNISTD_H=1 -DHAVE_DLFCN_H=1 -DNO_EXECUTE_PER
MISSION=1 -DALL_INTERIOR_POINTERS=1 -DGC_GCJ_SUPPORT=1 -DJAVA_FINALIZATION=1 -DATOMIC_UNCOLLECTABLE=1 -DL
ARGE_CONFIG=1 -I./include -fexceptions -I libatomic_ops/src -O2 -g -fPIC -m64 -MT atomic_ops.lo -MD -MP -
MF .deps/atomic_ops.Tpo -c atomic_ops.c -o atomic_ops.o >/dev/null 2>&1
make[2]: *** [all-recursive] Error 1
Error building BoehmGC.

real    0m36.506s
user    0m24.002s
sys     0m20.925s
sage: An error occurred while installing boehm_gc-7.1.p1
Please email sage-devel http://groups.google.com/group/sage-devel
explaining the problem and send the relevant part of

@williamstein

This comment has been minimized.

@sagetrac-drkirkby
Copy link
Mannequin

sagetrac-drkirkby mannequin commented Aug 31, 2009

comment:5

I checked your readline-6.0.spkg on Solaris 10 update 7. It builds fine with both Sun and GNU compilers. But the spkg still suffers from the issue of greping on the Suse file. I've created a new spkg

http://sage.math.washington.edu/home/kirkby/Solaris-fixes/readline-6.0/readline-6.0.spkg

which addresses this, but also does some other things that are not necessarily necessary for readline, but which can be helpful in general, to make a more robust spkg.

  • Upgrade to 6.0 (latest upstream) - see trac [with spkg's] port Sage to OS X 10.6 #6849
  • Remove numerous ugly build hacks needed only on OS X for older readline.
  • Track Clean up spkg-install for readline #6844 Made a test for /etc/SuSE-release, as the previous spkg-install
    greped on it, which generates a warning if the file does not
    exist, which it will not on most peoples systems.
  • Added '-m64' to CFLAGS, CXXFLAGS, FFLAGS and F77FLAGS
    if SAGE64 is set to 'yes'. I'm aware it is not necessary to do
    all of these in readline, but its better to stick to something that
    works on all packages.
  • Removes -m64 as a linker flag - no such linker flag exists.
  • Checks CC and CXX are not a mix of GNU and non-GNU compilers.
  • Added -Wall on gcc to show all warnings.
  • Adds -g by default, but it can be removed by setting
    SAGE_DEBUG to something other than 'yes'

You might notice that gcc gives a lot of compiler warnings now I've added -Wall. It's a wonder the package works at all.

Dave

@williamstein

This comment has been minimized.

@sagetrac-drkirkby
Copy link
Mannequin

sagetrac-drkirkby mannequin commented Sep 16, 2009

comment:8

I've made another improved version of the readline package - see

http://sage.math.washington.edu/home/kirkby/Solaris-fixes/readline-6.0-2nd-try/readline-6.0.spkg

I've made the upgrade of readline a new ticket (Update readline to version 6.0 #6945).

Dave

@williamstein
Copy link
Contributor Author

comment:9

I've made

@williamstein

This comment has been minimized.

@williamstein

This comment has been minimized.

@williamstein

This comment has been minimized.

@williamstein

This comment has been minimized.

@williamstein

This comment has been minimized.

@williamstein

This comment has been minimized.

@jhpalmieri
Copy link
Member

comment:15

It seems that the patch from #6883 is needed here to avoid a doctest failure in sage/interfaces/maxima.py. (This is for 10.6 and also 64-bit 10.5. With 32-bit 10.5, this file passes doctests with or without the patch.)

On 10.6, after building using the spkgs mentioned in the ticket, I have the following other doctest failures:

sage -t -long "devel/sage/sage/ext/fast_eval.pyx"           
**********************************************************************
File "/Applications/sage_builds/sage-4.1.2.alpha2-64bit/devel/sage/sage/ext/fast_eval.pyx", line 1080:
    sage: f(0.5)
Expected:
    0.5235987755982989...
Got:
    0.52359877559829882
**********************************************************************
1 items had failures:
   1 of   5 in __main__.example_32
***Test Failed*** 1 failures.
For whitespace errors, see the file /Applications/sage_builds/sage-4.1.2.alpha2-64bit/tmp/.doctest_fast_eval.py

sage -t -long "devel/sage/sage/functions/other.py"                
A mysterious error (perhaps a memory error?) occurred, which may have crashed doctest.

sage -t -long "devel/sage/sage/plot/text.py"                
A mysterious error (perhaps a memory error?) occurred, which may have crashed doctest.

sage -t -long "devel/sage/sage/rings/polynomial/pbori.pyx"  
A mysterious error (perhaps a memory error?) occurred, which may have crashed doctest.

sage -t -long "devel/sage/sage/symbolic/constants.py"       
A mysterious error (perhaps a memory error?) occurred, which may have crashed doctest.

sage -t -long "devel/sage/sage/symbolic/expression.pyx"     
A mysterious error (perhaps a memory error?) occurred, which may have crashed doctest.

sage -t -long "devel/sage/sage/symbolic/function.pyx"       
A mysterious error (perhaps a memory error?) occurred, which may have crashed doctest.

For instance, functions/other.py crashes Sage here:

sage: f = factorial(x + factorial(x))
/Applications/sage_builds/sage-4.1.2.alpha2/local/bin/sage-sage: line 199:   5554 Abort trap        sage-ipython "$@" -i

sage/symbolic/expression.pyx crashes on the line float(SR(RIF(Integer(2)))) with a similar message. (I'm typing these on one computer while testing on another -- I'm not cut-and-pasting, so apologies for any typos.)

Setting SAGE64 to "yes" resulting in a build with the same doctest failures. I don't know if setting SAGE64 to "yes" has any actual effect, but it does have cosmetic effects: first, when building a package like readline, without SAGE64, I get the message "Building a 32-bit version of Readline", but the resulting library is 64-bit. Also, when SAGE64 is set, then compiler flags (for example when building bzip2) include "-m64". I don't know if these are just cosmetic, or if they have a more serious effect.

On 10.5, using these spkgs, I get some failures with the 32-bit build, but these are known: see this thread.

On 10.5, 64-bit build, all tests pass!

@sagetrac-mvngu
Copy link
Mannequin

sagetrac-mvngu mannequin commented Sep 26, 2009

Attachment: testlong-4.1.2.alpha2-updated-spkg-bsd.math.log

doctest log for bsd.math OS X 10.6

@sagetrac-mvngu
Copy link
Mannequin

sagetrac-mvngu mannequin commented Sep 26, 2009

doctest log for cicero on SkyNet 32-bit Fedora 9

@sagetrac-mvngu
Copy link
Mannequin

sagetrac-mvngu mannequin commented Sep 27, 2009

comment:16

Attachment: testlong-4.1.2.alpha2-updated-spkg-cicero-skynet.log

Here is John Palmieri's report from sage-devel:

> * #6969 boehm_gc-7.1.p2.spkg
> * #6971 ecl-9.8.4-20090913cvs.p1.spkg
> * #7006 mpir-1.2.p6.spkg
> * #6919 flint-1.5.0.p0.spkg
> * #6990 python-2.6.2.p2.spkg
> * #6951 singular-3-1-0-4-20090818.p0.spkg
> * #6758 libgcrypt-1.4.3.p2.spkg
> * #6681 cliquer-1.2.p0.spkg

In an attempt to save time, I attempted to build using all of these at
once (instead of doing one at a time), along with the new fortran spkg
(#6981) and the new r spkg (#6972).  On OS X 10.5, both 32-bit and 64-
bit, building was successful.  After applying the appropriate patches
-- the ones from 6883, 6919, 6972 -- 64-bit: all tests passed.  After
applying these patches to the 32-bit build, same failures as Minh
reported in another thread ("Sage 4.1.2.alpha2 doctest failures on OS
X 10.5.8").

In other words, the packages seem to all look good.  I have not
examined each one to see if the spkg-install files make sense, for
instance, but from the point of view of building and (apparently)
functioning on OS X 10.5, they work.

I don't have the energy to comment on each ticket individually, so
take this as my portion of a positive review for each ticket: on Mac
OS X 10.5, they build properly and seem to work.

Here is my report. I compiled Sage 4.1.2.alpha2 from scratch with the following packages:

The building machines are:

  • bsd.math: x86 Mac OS X 10.6 --- compile: yes; doctest pass: no. Full log is attached.
  • sage.math: x86_64 Ubuntu 8.04.3 LTS --- compile: yes; doctest pass: yes
  • rosemary.math: x86_64 RHEL 5.4 --- compile: yes; doctest pass: yes
  • cicero on SkyNet: x86 Fedora 9 --- compile: yes; doctest pass: no. The failed tests are:
sage -t -long "devel/sage/sage/misc/randstate.pyx"
sage -t -long "devel/sage/sage/rings/polynomial/pbori.pyx"
sage -t -long "devel/sage/sage/interfaces/gp.py"
sage -t -long "devel/sage/sage/interfaces/expect.py"
sage -t -long "devel/sage/sage/interfaces/sage0.py"
sage -t -long "devel/sage/sage/crypto/boolean_function.pyx"
sage -t -long "devel/sage/sage/server/simple/twist.py"

which have been reported before to sage-devel.

  • eno on SkyNet: x86_64 Fedora 9 --- compile: yes; doctest pass: yes
  • lena on SkyNet: x86_64 RHEL 5.3 --- compile: yes; doctest pass: yes
  • menas on SkyNet: x86_64 openSUSE 11.1 --- compile: yes; doctest: yes

Positive review from me. Any doctest failures are to be fixed in upcoming rc release(s). At the moment, there are so many packages with porting work to Cygwin and OS X 10.6. I'm happy that those packages build OK on Cygwin and OS X 10.6.

@sagetrac-mvngu
Copy link
Mannequin

sagetrac-mvngu mannequin commented Sep 27, 2009

Author: William Stein

@sagetrac-mvngu
Copy link
Mannequin

sagetrac-mvngu mannequin commented Sep 27, 2009

Reviewer: John Palmieri, Minh Van Nguyen

@williamstein

This comment has been minimized.

@williamstein williamstein modified the milestones: sage-4.2, sage-4.1.2 Oct 2, 2009
@williamstein williamstein changed the title port Sage to OS X 10.6 [with spkg's] port Sage to OS X 10.6 Oct 2, 2009
@williamstein
Copy link
Contributor Author

comment:21

I'm closing this metaticket. There is one remaining issue, but that is now at #6849.

@jasongrout
Copy link
Member

comment:23

Replying to @williamstein:

I'm closing this metaticket. There is one remaining issue, but that is now at #6849.

This is #6849. Surely you meant another ticket?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants