Porting to "El Capitan" (OS X 10.11) #19370

kiwifb · 2015-10-07T21:59:01Z

Currently sage is not working at all on OS X 10.11. The aim of this ticket is to remedy to that.

Points identified so far:

Libraries which do not have a properly set install_name fail to load
The fix for osx R spkg error: expected ',' or '}' before '__attribute__' #18254 (R) should have been applied more widely on future release
The fix for building git without openssl on OS X in Update to git 2.1.2 #17091 is not working anymore and needs replacing with something less subtle

Will all these problems fix sage can build an run on OS X 10.11. This ticket is only concerned with building sage, issues about binary distribution and checking of optional packages is left for other tickets.

CC: @jhpalmieri @sagetrac-yomcat @cnassau

Component: porting

Author: François Bissey, R. Andrew Ohana

Branch: d3f5e99

Reviewer: François Bissey, Andrew Ohana, Christian Nassau

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

The text was updated successfully, but these errors were encountered:

kiwifb · 2015-10-07T22:04:18Z

comment:1

Some of the bits included in the patch are clean up:

cliquer: removed MACOSX_DEPLOYMENT_TARGET, this is set globaly and putting 10.3 means rpath cannot be used if we go that route (bit me when the first version of this was focusing on rpathing everything)
conway_polynomials: the modification enable it to be installed without segfaulting sage. The import statement is pinpointed to the only needed bit.
git: openssl was first disabled if you use 10.8 and then just disabled on any OS X.

sagetrac-git · 2015-10-07T23:19:29Z

Changed commit from c953b2e to f39401a

sagetrac-git · 2015-10-07T23:19:29Z

Branch pushed to git repo; I updated commit sha1. New commits:

`f39401a`	`Fix basic install_name problems in R - inspired by Gentoo prefix.`

kiwifb · 2015-10-08T01:14:34Z

comment:4

Building with SAGE_DEBUG=1 to try to get to the root of the present segfault. maxima will not build on top of ecl built with SAGE_DEBUG=1 (regardless of setting for maxima itself). I do not know if it is unique to El Capitan.

kiwifb · 2015-10-08T04:27:23Z

comment:5

Replying to @kiwifb:

Building with SAGE_DEBUG=1 to try to get to the root of the present segfault. maxima will not build on top of ecl built with SAGE_DEBUG=1 (regardless of setting for maxima itself). I do not know if it is unique to El Capitan.

And same thing with zn_poly compiled against mpir with SAGE_DEBUG=1. Again I am not sure it is specific to El Capitan.

jhpalmieri · 2015-10-08T05:40:52Z

comment:7

Do you mean SAGE_DEBUG=yes? I don't see any reason why SAGE_DEBUG=1 would have any effect. In any case, I just tried a build on OS X 10.10 with SAGE_DEBUG=1 and it went fine. Now I'm trying with SAGE_DEBUG=yes. I'll report on the results tomorrow.

kiwifb · 2015-10-08T06:16:39Z

comment:8

I thought the important bit was for SAGE_DEBUG to be defined but may be some spkg-install look specifically for yes.

kiwifb · 2015-10-08T06:48:49Z

comment:9

things get out of hands with singular when compiled with SAGE_DEBUG=yes (and it has to be yes) some symbols are in other libraries that are not linked into sage on OS X.

ImportError: dlopen(/Users/fbissey/build/sage-6.7.beta4/local/lib/python2.7/site-packages/sage/rings/polynomial/multi_polynomial_libsingular.so, 2): Symbol not found: _om_BinPageIndicies
  Referenced from: /Users/fbissey/build/sage-6.7.beta4/local/lib/python2.7/site-packages/sage/rings/polynomial/multi_polynomial_libsingular.so
  Expected in: /Users/fbissey/build/sage-6.7.beta4/local/lib/libsingular.dylib
 in /Users/fbissey/build/sage-6.7.beta4/local/lib/python2.7/site-packages/sage/rings/polynomial/multi_polynomial_libsingular.so

and

Mirage:sage-6.7.beta4 fbissey$ nm local/lib/libsingular.dylib | grep  _om_BinPageIndicies
Mirage:sage-6.7.beta4 fbissey$ 
Mirage:sage-6.7.beta4 fbissey$ nm local/lib/libomalloc.a | grep  _om_BinPageIndicies
warning: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/nm: no name list
warning: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/nm: no name list
0000000000007758 S _om_BinPageIndicies
                 U _om_BinPageIndicies
                 U _om_BinPageIndicies
                 U _om_BinPageIndicies
                 U _om_BinPageIndicies
                 U _om_BinPageIndicies
                 U _om_BinPageIndicies

Unfortunately libomalloc is not linked into sage as far as I can see.

jhpalmieri · 2015-10-08T14:57:39Z

comment:10

Run the command grep -R SAGE_DEBUG build/pkgs/ to see the uses of SAGE_DEBUG: most test whether it is "yes".

On OS X 10.10 with SAGE_DEBUG=yes for the entire Sage build, maxima fails to build, zn_poly and singular build successfully. (I do not have SAGE_CHECK set, by the way.)

kiwifb · 2015-10-08T21:36:30Z

comment:11

OK retrying with SAGE_DEBUG=yes I should have thought of grepping. Interesting that maxima fails when ecl has debug code. There are a few extra things that seem to be required to link when sage itself is not compiled with -DNDEBUG, at least on OS X but that's possibly a different issue.

vbraun · 2015-10-08T23:02:19Z

comment:12

For the record, the symbol is indeed in libsingular on OSX10.10:

$ nm local/lib/libsingular.dylib | grep  _om_BinPageIndicies
0000000000674a58 S _om_BinPageIndicies

kiwifb · 2015-10-08T23:04:44Z

comment:13

Thanks for the info Volker, I will have to check if it is, in a non-debug build of singular.

vbraun · 2015-10-08T23:05:53Z

comment:14

PS: The libsingular compile log (logs/pkgs/singular-3.1.7p1.p0.log) shows that it links against omalloc. Maybe double check that its not the Singular build system's fault

g++ -dynamiclib -twolevel_namespace -weak_reference_mismatches weak -undefined dynamic_lookup -L/Users/vbraun/Sage/local/lib -lflint -lmpfr -lmpir -single_module -o libsingular.dylib \
        iparith.o mpsr_Tok.o claptmpl.o \
        grammar.o scanner.o attrib.o blackbox.o eigenval_ip.o extra.o fehelp.o feOpt.o ipassign.o ipconv.o ipid.o iplib.o ipprint.o ipshell.o newstruct.o lists.o sdb.o fglm.o interpolation.o silink.o ssiLink.o s_buff.o subexpr.o janet.o wrapper.o libparse.o sing_win.o gms.o pcv.o maps_ip.o walk.o walk_ip.o cntrlc.o misc_ip.o calcSVD.o pipeLink.o Minor.o MinorProcessor.o MinorInterface.o bigintm.o pyobject_setup.o denom_list.o minpoly.o countedref.o singmathic.o semaphore.o rlimit.o slInit_Static.o mpsr_Put.o mpsr_PutPoly.o mpsr_GetPoly.o mpsr_sl.o mpsr_Get.o mpsr_GetMisc.o mpsr_Error.o ndbm.o sing_dbm.o -lkernel -L../kernel -L../factory -L../libfac -L/Users/vbraun/Sage/local/lib -lsingfac -lsingcf -lntl -lreadline -L/Users/vbraun/Sage/local/lib -lflint -lmpfr -lmpir -lgmp -lomalloc

vbraun · 2015-10-08T23:07:43Z

comment:15

PPS: let me know if you want an account on the OSX 10.10 buildbot to compare with...

kiwifb · 2015-10-08T23:13:22Z

comment:16

I'll think about the offer but I may be too split for time to run things on the two fronts at the same time. I will definitely check what happens here regarding singular.

I really need to get a debug build in shape if I want to track that segfault.

kiwifb · 2015-10-09T02:29:20Z

comment:17

OK I think the singular problem was due to left over stuff from an install without SAGE_DEBUG=yes first before a properly built version with debugging enabled. It looks all right now.

But debugging doesn't come easy

Mirage:sage-6.7.beta4 fbissey$ ./sage -gdb
┌────────────────────────────────────────────────────────────────────┐
│ SageMath Version 6.9.rc2, Release Date: 2015-10-03                 │
│ Type "notebook()" for the browser-based notebook interface.        │
│ Type "help()" for help.                                            │
└────────────────────────────────────────────────────────────────────┘
┏━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━┓
┃ Warning: this is a prerelease version, and it may be unstable.     ┃
┗━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━┛
Forcing sage-location, probably because a new package was installed.
Updating various hardcoded paths...
(Please wait at most a few minutes.)
DO NOT INTERRUPT THIS.
Done updating paths.
GNU gdb (GDB) 7.8
Copyright (C) 2014 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-apple-darwin15.0.0".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
<http://www.gnu.org/software/gdb/documentation/>.
For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from python...
warning: `/Users/fbissey/build/sage-6.7.beta4/local/var/tmp/sage/build/python2-2.7.9/src/Modules/python.o': can't open to read symbols: No such file or directory.
(no debugging symbols found)...done.
warning: `/Users/fbissey/build/sage-6.7.beta4/local/var/tmp/sage/build/python2-2.7.9/src/Modules/python.o': can't open to read symbols: No such file or directory.
Python Exception <class 'cElementTree.ParseError'> no element found: line 1, column 0: 
/var/folders/0g/jzxs892s22dflvl1ccnj98hh0000gn/T/tmp38HlSs:557: Error in sourced command file:
Error occurred in Python command: no element found: line 1, column 0
/Users/fbissey/build/sage-6.7.beta4/local/bin/sage-gdb-commands:1: Error in sourced command file:
Unable to find Mach task port for process-id 98761: (os/kern) failure (0x5).
 (please check gdb is codesigned - see taskgated(8))
(gdb) q
close failed in file object destructor:
IOError: [Errno 9] Bad file descriptor

anyone has a clue?

vbraun · 2015-10-09T08:38:25Z

comment:18

Thats normal, a self-compiled gdb lacks permissions on OSX to debug. Run gdb as root or figure out how to properly codesign it (the latter didn't work for me when I tried once it but is supposed to work).

kiwifb · 2015-10-09T09:38:11Z

comment:19

feeling really silly I should know that. May have to cut some optimization and avoid stripping.

#0  0x0000000106adaf1b in get_adjusted_ptr(std::type_info const*, std::type_info const*, void**) () from /Users/fbissey/build/sage-6.7.beta4/local/lib/libstdc++.6.dylib
#1  0x0000000106adb7c9 in __gxx_personality_v0 () from /Users/fbissey/build/sage-6.7.beta4/local/lib/libstdc++.6.dylib
#2  0x00007fff8490a9ba in _Unwind_RaiseException () from /usr/lib/system/libunwind.dylib
#3  0x0000000106adbe39 in __cxa_rethrow () from /Users/fbissey/build/sage-6.7.beta4/local/lib/libstdc++.6.dylib
#4  0x000000010e5d39e2 in __pyx_f_4sage_8symbolic_8function_15BuiltinFunction__is_registered(__pyx_obj_4sage_8symbolic_8function_BuiltinFunction*) ()
   from /Users/fbissey/build/sage-6.7.beta4/local/lib/python2.7/site-packages/sage/symbolic/function.so
#5  0x000000010e5b083d in __pyx_pf_4sage_8symbolic_8function_8Function___init__(__pyx_obj_4sage_8symbolic_8function_Function*, _object*, _object*, _object*, _object*, _object*, _object*) () from /Users/fbissey/build/sage-6.7.beta4/local/lib/python2.7/site-packages/sage/symbolic/function.so
#6  0x000000010e5af5dc in __pyx_pw_4sage_8symbolic_8function_8Function_1__init__(_object*, _object*, _object*) ()
   from /Users/fbissey/build/sage-6.7.beta4/local/lib/python2.7/site-packages/sage/symbolic/function.so
#7  0x00000001000b4461 in wrap_init () from /Users/fbissey/build/sage-6.7.beta4/local/lib/libpython2.7.dylib
#8  0x000000010003a12b in wrapper_call () from /Users/fbissey/build/sage-6.7.beta4/local/lib/libpython2.7.dylib
#9  0x0000000100014e89 in PyObject_Call () from /Users/fbissey/build/sage-6.7.beta4/local/lib/libpython2.7.dylib
#10 0x0000000100122f94 in PyEval_CallObjectWithKeywords () from /Users/fbissey/build/sage-6.7.beta4/local/lib/libpython2.7.dylib
#11 0x0000000100039156 in wrapperdescr_call () from /Users/fbissey/build/sage-6.7.beta4/local/lib/libpython2.7.dylib
#12 0x000000010e5ec75e in __Pyx_PyObject_Call(_object*, _object*, _object*) ()
   from /Users/fbissey/build/sage-6.7.beta4/local/lib/python2.7/site-packages/sage/symbolic/function.so
#13 0x000000010e5cdd52 in __pyx_pf_4sage_8symbolic_8function_15BuiltinFunction___init__(__pyx_obj_4sage_8symbolic_8function_BuiltinFunction*, _object*, _object*, _object*, _object*, _object*, _object*) () from /Users/fbissey/build/sage-6.7.beta4/local/lib/python2.7/site-packages/sage/symbolic/function.so
#14 0x000000010e5cd660 in __pyx_pw_4sage_8symbolic_8function_15BuiltinFunction_1__init__(_object*, _object*, _object*) ()
   from /Users/fbissey/build/sage-6.7.beta4/local/lib/python2.7/site-packages/sage/symbolic/function.so
#15 0x00000001000b4461 in wrap_init () from /Users/fbissey/build/sage-6.7.beta4/local/lib/libpython2.7.dylib
#16 0x000000010003a12b in wrapper_call () from /Users/fbissey/build/sage-6.7.beta4/local/lib/libpython2.7.dylib

at least we are starting to get somewhere.

vbraun · 2015-10-09T09:52:09Z

comment:20

Looks like it uses the system clang _Unwind_RaiseException, whereas it should be using the one from SAGE_ROOT/local/lib/libgcc

kiwifb · 2015-10-09T10:10:44Z

comment:21

Yes I can find the symbol in libgcc_s_x86_64.1.dylib. I may have to re-attempt rpath-ing the whole thing. I am fairly sure that the first time I only managed to rpath all the dylibs, unfortunately python modules, still in .so in vanilla sage, are bundles which is a different linking option on OS X.

cnassau · 2015-10-10T16:02:29Z

comment:22

I just got El Capitan running on a virtual machine! To celebrate, I tried a sage-build based on this ticket's branch. I get segfaults in zn_poly and maxima (among other things). Both seem to be alignment-problems; here is the backtrace for maxima, running ecl:

(sage-sh) cn@el-capitan:src$ gdb ecl
GNU gdb (GDB) 7.8
...
(gdb) run
...
Program received signal SIGSEGV, Segmentation fault.
0x00007fff89cf32da in stack_not_16_byte_aligned_error () from /usr/lib/system/libdyld.dylib
(gdb) where
#0  0x00007fff89cf32da in stack_not_16_byte_aligned_error () from /usr/lib/system/libdyld.dylib
#1  0x00007fff5fbfeee0 in ?? ()
#2  0x00000001002c22b8 in ?? () from /Users/cn/sage/local/lib//libecl.15.3.dylib
#3  0x0000000000002364 in ?? ()
#4  0x0000000100175081 in ecl_char_upcase () from /Users/cn/sage/local/lib//libecl.15.3.dylib
#5  0x00000001001c25df in _hash_equalp () from /Users/cn/sage/local/lib//libecl.15.3.dylib
#6  0x00000001001c26c7 in _hash_equalp () from /Users/cn/sage/local/lib//libecl.15.3.dylib
#7  0x00000001001c32aa in _ecl_sethash_equalp () from /Users/cn/sage/local/lib//libecl.15.3.dylib
#8  0x00000001001c3db4 in ecl_sethash () from /Users/cn/sage/local/lib//libecl.15.3.dylib
#9  0x0000000100004c4d in cl_boot () from /Users/cn/sage/local/lib//libecl.15.3.dylib
#10 0x0000000100000df1 in main ()

I think there is a chance these might be misconfigurations as a consequence of the virtualisation, but I thought I'd share this anyway...

cnassau · 2015-10-11T09:44:24Z

comment:24

Replying to @cnassau:

With SAGE_CHECK=yes I get two test failures (segfaults from t-divrem_1, t-fat) from gmp. These seem to be similar to the ones described here for gmp-6.0.0 on Yosemite: https://gmplib.org/list-archives/gmp-bugs/2014-June/003499.html

Debugging this with gdb seems difficult; all I manage to get (from running test t-divrem_1) is

Program received signal SIGSEGV, Segmentation fault.
0x00007fff911b92da in stack_not_16_byte_aligned_error () from /usr/lib/system/libdyld.dylib
(gdb) where
Python Exception <type 'exceptions.ImportError'> dlopen(/Users/cn/sage/local/lib/python2.7/lib-dynload/itertools.so, 2): Symbol not found: __Py_RefTotal
  Referenced from: /Users/cn/sage/local/lib/python2.7/lib-dynload/itertools.so
  Expected in: flat namespace
 in /Users/cn/sage/local/lib/python2.7/lib-dynload/itertools.so: 
#0  0x00007fff911b92da in stack_not_16_byte_aligned_error () from /usr/lib/system/libdyld.dylib
#1  0x0000000000000000 in ?? ()

kiwifb · 2015-10-11T21:01:28Z

comment:25

Replying to @cnassau:

I just got El Capitan running on a virtual machine! To celebrate, I tried a sage-build based on this ticket's branch. I get segfaults in zn_poly and maxima (among other things). Both seem to be alignment-problems; here is the backtrace for maxima, running ecl:

(sage-sh) cn@el-capitan:src$ gdb ecl
GNU gdb (GDB) 7.8
...
(gdb) run
...
Program received signal SIGSEGV, Segmentation fault.
0x00007fff89cf32da in stack_not_16_byte_aligned_error () from /usr/lib/system/libdyld.dylib
(gdb) where
#0  0x00007fff89cf32da in stack_not_16_byte_aligned_error () from /usr/lib/system/libdyld.dylib
#1  0x00007fff5fbfeee0 in ?? ()
#2  0x00000001002c22b8 in ?? () from /Users/cn/sage/local/lib//libecl.15.3.dylib
#3  0x0000000000002364 in ?? ()
#4  0x0000000100175081 in ecl_char_upcase () from /Users/cn/sage/local/lib//libecl.15.3.dylib
#5  0x00000001001c25df in _hash_equalp () from /Users/cn/sage/local/lib//libecl.15.3.dylib
#6  0x00000001001c26c7 in _hash_equalp () from /Users/cn/sage/local/lib//libecl.15.3.dylib
#7  0x00000001001c32aa in _ecl_sethash_equalp () from /Users/cn/sage/local/lib//libecl.15.3.dylib
#8  0x00000001001c3db4 in ecl_sethash () from /Users/cn/sage/local/lib//libecl.15.3.dylib
#9  0x0000000100004c4d in cl_boot () from /Users/cn/sage/local/lib//libecl.15.3.dylib
#10 0x0000000100000df1 in main ()

I think there is a chance these might be misconfigurations as a consequence of the virtualisation, but I thought I'd share this anyway...

Well I had to build ecl without SAGE_DEBUG=yes for maxima to build. Same thing with zn_poly, I had to build mpir without SAGE_DEBUG=yes for it to build.

cnassau · 2015-10-11T21:20:15Z

comment:26

I think we are hit by this incredibly trivial (and incredibly powerful) bug in the gmp build-system: https://lists.macosforge.org/pipermail/macports-tickets/2014-September/170442.html

The problem is that OS 10.10 and OS 10.11 are erroneously recognized as OSX 10.1 (!) Among other things this leads to a corrupted gcc which is hit by internal compiler errors when optimization is turned on.

I have added a (somewhat hasty) patch for gmp which at least fixes the two test failures t-divrem_1 and t-fat. This patch is on the trac branch u/cnassau/capitan . The gmp test-suite still fails, but now at a later stage (cxx).

vbraun · 2015-10-11T22:25:13Z

comment:27

That bug is old. It can be worked around by setting MACOSX_DEPLOYMENT_TARGET=10.9, see src/bin/sage-env. The latter file almost certainly needs to be updated to also set it for 10.11

cnassau · 2015-10-12T09:11:15Z

comment:28

Indeed, with the obvious "fix" in sage-env I could now build all of sage and start running the doctests. My 40G harddrive overflowed during the build because I kept the full installation logs (sigh), and I now get plenty of doctest failures, apparently due to missing packages (sympy, conway_polynomials, ...). Will have to rebuild, it seems...

cnassau · 2015-10-14T07:13:20Z

comment:36

Replying to @kiwifb:

OK testing it. Andrew, is it ok if I review your changes and you review mine? I guess Christian can do some reviewing too. That would mean we would have one reviewer that is not also an author.

Andrew's last changes for lcalc also fixes the one doctest failure that I saw previously. "make ptest" works for me now, so I think compile-wise everything is as it should be.

I have a couple of issues on my mind that I think should be addressed. Pls feel free to convince me that these are non-issues and/or better addressed in a different ticket:

testing compilation of optional packages (so far no tests have been done)
how do we deal with the fact that the resulting sage is broken when you move it to a different folder?

This second issue is not fixable by changing compilation options, I believe, so we should just forbid relocation. I think something like this is required:

"sage --bdist" should build sage in the directory "/Application/SageMath-$Version-..." and sage will only run in this directory.
The README in the resulting app should be updated to say that the Sage icon should be dragged into the Application folder. Alternatively, we should implement an installer.
sage should print a warning "This copy of sage can only be run in dirctory /Application/Sage..." and exit.

kiwifb · 2015-10-14T07:38:41Z

comment:37

Thanks for your comments Christian. I believe they raise very important point.

In this ticket I focused on getting sage to build, but we may need to emphasise that it is not currently relocatable at the end of the build process somewhere. There may be ways to fix that situation in the future but unless someone builds a special tool the task is complicated.

The suggestion of building in a standard location to produce redistributable binaries is interesting.

Some optional packages may have similar issues with install_name that singular and al were displaying. Those should be inspected and fixed.

But I think we have an important milestone, sage can be built on El Capitan and I think after adding a warning we should merge it immediately. I also should note that this ticket basically fixed outstanding issues from other old tickets (#16044 and #17513 were basically all about fixing install_names and it is now done properly). I would argue that it generally improves the quality of the build on any version of OS X.

Issues about producing binaries, optional package and so on can be put in a follow up ticket, let people be able to build the thing.

cnassau · 2015-10-14T07:54:40Z

comment:38

But I think we have an important milestone, sage can be built on El Capitan and I think after adding a warning we should merge it immediately.

No problem. Could you maybe create a new ticket for the follow up issues? I'd be happy to set this ticket back to positive-review then.

sagetrac-yomcat · 2015-10-14T08:57:53Z

comment:39

The branch didn't work for me:

Error building the documentation.

Note: incremental documentation builds sometimes cause spurious
error messages. To be certain that these are real errors, run
"make doc-clean" first and try again.
Traceback (most recent call last):
  File "/Applications/sage-devel/src/doc/common/builder.py", line 1626, in <module>
    getattr(get_builder(name), type)()
  File "/Applications/sage-devel/src/doc/common/builder.py", line 292, in _wrapper
    getattr(get_builder(document), 'inventory')(*args, **kwds)
  File "/Applications/sage-devel/src/doc/common/builder.py", line 503, in _wrapper
    x.get(99999)
  File "/Applications/sage-devel/local/lib/python/multiprocessing/pool.py", line 558, in get
    raise self._value
OSError: [polynomia] /Applications/sage-devel/src/doc/en/reference/polynomial_rings/index.rst:7: WARNING: toctree contains reference to nonexisting document u'sage/rings/polynomial/polynomial_ring_constructor'

make[2]: *** [doc-html] Error 1
make[1]: *** [all] Error 2

real	28m59.891s
user	106m18.548s
sys	10m28.679s
***************************************************************
Error building Sage.

The following package(s) may have failed to build (not necessarily
during this run of 'make all'):

* documentation: dochtml
  log file: /Applications/sage-devel/logs/pkgs/../dochtml.log

The build directory may contain configuration files and other potentially
helpful information. WARNING: if you now run 'make' again, the build
directory will, by default, be deleted. Set the environment variable
SAGE_KEEP_BUILT_SPKGS to 'yes' to prevent this.

make: *** [all] Error 1
Cade:sage-devel yomcat$ ./sage
┌────────────────────────────────────────────────────────────────────┐
│ SageMath Version 6.9, Release Date: 2015-10-10                     │
│ Type "notebook()" for the browser-based notebook interface.        │
│ Type "help()" for help.                                            │
└────────────────────────────────────────────────────────────────────┘
Forcing sage-location, probably because a new package was installed.
Updating various hardcoded paths...
(Please wait at most a few minutes.)
DO NOT INTERRUPT THIS.
Done updating paths.

**********************************************************************

Oops, Sage crashed. We do our best to make it stable, but...

A crash report was automatically generated with the following information:
  - A verbatim copy of the crash traceback.
  - A copy of your input history during this session.
  - Data on your current Sage configuration.

It was left in the file named:
	'/Users/yomcat/.sage/ipython_genutils-0.1.0/Sage_crash_report.txt'
If you can email this file to the developers, the information in it will help
them in understanding and correcting the problem.

You can mail it to: sage-support at sage-support@googlegroups.com
with the subject 'Sage Crash Report'.

If you want to do it now, the following command will work (under Unix):
mail -s 'Sage Crash Report' sage-support@googlegroups.com < /Users/yomcat/.sage/ipython_genutils-0.1.0/Sage_crash_report.txt

To ensure accurate tracking of this issue, please file a report about it at:
http://trac.sagemath.org

Hit <Enter> to quit (your terminal may close):

I may have done something wrong however.

cnassau · 2015-10-14T09:16:22Z

comment:40

Replying to @sagetrac-yomcat:
Hard to say what the problem could be without looking into the build logs. I would suggest to try a (very) clean rebuild first, using a fresh checkout; without the fixes in this branch you might end up with a corrupted "gcc" in local/bin, and that potentially messes up every subsequent build in the same installation. I would suggest to

use a fresh checkout
make sure the environment is sane (no CC, CXX, CFLAGS, etc.)
build single-threaded, i.e. no MAKE="make -j..."

If this also fails it might help to post the full build log somewhere.

sagetrac-yomcat · 2015-10-14T17:50:43Z

comment:41

Replying to @cnassau:

I redid the build with a make distclean (I did this the first time, but I think something went wrong with it), followed by export MAKE="make -j6"; make ptestlong, and all tests passed.

cnassau · 2015-10-14T18:10:05Z

comment:42

Replying to @sagetrac-yomcat:

Replying to @cnassau:

I redid the build with a make distclean (I did this the first time, but I think something went wrong with it), followed by export MAKE="make -j6"; make ptestlong, and all tests passed.

Wonderful! I'll give this ticket its positive review back then.

cnassau · 2015-10-14T18:10:05Z

Changed reviewer from François Bissey, Andrew Ohana to François Bissey, Andrew Ohana, Christian Nassau

cnassau · 2015-10-14T18:18:42Z

comment:43

Replying to @cnassau:

But I think we have an important milestone, sage can be built on El Capitan and I think after adding a warning we should merge it immediately.

No problem. Could you maybe create a new ticket for the follow up issues? I'd be happy to set this ticket back to positive-review then.

I have now created #19410 for this.

kiwifb · 2015-10-14T20:30:59Z

comment:44

We could support "upgrading" to El Capitan by bumping the versions of lcalc, R, singular and cliquer. That would force their rebuild.

jhpalmieri · 2015-10-15T23:02:08Z

comment:45

With this branch on OS X 10.11, Cython failed its test suite for me. See [log file http://www.math.washington.edu/~palmieri/Sage/cython-0.23.1.p0.log].

Should we set this back to "needs work"?

(I also had a failure with gf2x, but I think that was an instance of #18882. It passed its test suite when I ran it a second time.)

kiwifb · 2015-10-15T23:14:24Z

comment:46

I am quite unwilling to put it back to work personally but this needs investigating. Would upgrading cython to 0.23.3 (#19334) improve the situation? And of course is it an El Capitan only problem or does it show up anywhere else?

vbraun · 2015-10-16T00:31:34Z

comment:47

Just do it on a separate ticket.

jhpalmieri · 2015-10-16T00:34:51Z

comment:48

I see the same problem on OS X 10.10, so let's keep this as "positive review".

kcrisman · 2015-10-16T01:47:17Z

comment:49

But I think we have an important milestone, sage can be built on El Capitan and I think after adding a warning we should merge it immediately. I also should note that this ticket basically fixed outstanding issues from other old tickets (#16044 and #17513 were basically all about fixing install_names and it is now done properly). I would argue that it generally improves the quality of the build on any version of OS X.

So would you feel that #16044 is now invalid/fixed? Certainly that would seem to be the case, though the relocation issue isn't fixed, I guess. Anyway I have now finally given up on building anything after Sage 6.4.1 on PPC Macs because of a few different issues, not least of which is the continued upward spiral of gcc versions. (Naturally one definitely can build it! But not so easily from scratch, you must first build a newer gcc to build the newest gcc, and that's not automatic enough for me to bother with it.)

kiwifb · 2015-10-16T01:51:32Z

comment:50

I suggest we mark it won't fix. I have no machine and no intentions to test this on Tiger. But yes in principle it would solve the issues. Funny that I was kind of force to push a branch to get sage to build on a new version of OS X with fix that were spotted that far back (and for which there was solutions that far back too).

vbraun · 2015-10-16T08:22:25Z

Changed branch from u/ohanar/elcapitan to d3f5e99

fchapoton · 2017-07-19T09:22:52Z

Changed commit from d3f5e99 to none

fchapoton · 2017-07-19T09:22:52Z

Changed author from François Bissey, Andrew Ohana to François Bissey, R. Andrew Ohana

fchapoton · 2017-07-19T09:22:52Z

comment:52

for uniqueness of names

kiwifb added this to the sage-6.9 milestone Oct 7, 2015

kiwifb added c: porting labels Oct 7, 2015

kiwifb added the s: positive review label Oct 14, 2015

cnassau added s: needs work and removed s: positive review labels Oct 14, 2015

cnassau added s: positive review and removed s: needs work labels Oct 14, 2015

This comment has been minimized.

Sign in to view

vbraun removed the s: positive review label Oct 16, 2015

vbraun closed this as completed in 1f43e02 Oct 16, 2015

cnassau mentioned this issue Jan 7, 2016

Fix OSX App package, forbid relocation on OSX #19410

Closed

vbraun mentioned this issue Nov 30, 2015

Make binaries installable #19467

Closed

Porting to "El Capitan" (OS X 10.11) #19370

Porting to "El Capitan" (OS X 10.11) #19370

Comments

kiwifb commented Oct 7, 2015

kiwifb commented Oct 7, 2015

sagetrac-git mannequin commented Oct 7, 2015

sagetrac-git mannequin commented Oct 7, 2015

kiwifb commented Oct 8, 2015

kiwifb commented Oct 8, 2015

jhpalmieri commented Oct 8, 2015

kiwifb commented Oct 8, 2015

kiwifb commented Oct 8, 2015

jhpalmieri commented Oct 8, 2015

kiwifb commented Oct 8, 2015

vbraun commented Oct 8, 2015

kiwifb commented Oct 8, 2015

vbraun commented Oct 8, 2015

vbraun commented Oct 8, 2015

kiwifb commented Oct 8, 2015

kiwifb commented Oct 9, 2015

vbraun commented Oct 9, 2015

kiwifb commented Oct 9, 2015

vbraun commented Oct 9, 2015

kiwifb commented Oct 9, 2015

cnassau commented Oct 10, 2015

cnassau commented Oct 11, 2015

kiwifb commented Oct 11, 2015

cnassau commented Oct 11, 2015

vbraun commented Oct 11, 2015

cnassau commented Oct 12, 2015

cnassau commented Oct 14, 2015

kiwifb commented Oct 14, 2015

cnassau commented Oct 14, 2015

sagetrac-yomcat mannequin commented Oct 14, 2015

cnassau commented Oct 14, 2015

sagetrac-yomcat mannequin commented Oct 14, 2015

cnassau commented Oct 14, 2015

cnassau commented Oct 14, 2015

cnassau commented Oct 14, 2015

kiwifb commented Oct 14, 2015

This comment has been minimized.

jhpalmieri commented Oct 15, 2015

kiwifb commented Oct 15, 2015

vbraun commented Oct 16, 2015

jhpalmieri commented Oct 16, 2015

kcrisman commented Oct 16, 2015

kiwifb commented Oct 16, 2015

vbraun commented Oct 16, 2015

fchapoton commented Jul 19, 2017

fchapoton commented Jul 19, 2017

fchapoton commented Jul 19, 2017