#29408 closed defect (fixed)

Fix build errors with pplpy, scipy, kiwisolver, fpylll on macos with system python3

Reported by: mkoeppe Owned by:
Priority: blocker Milestone: sage-9.1
Component: packages: standard Keywords:
Cc: dimpase, vdelecroix, fbissey, gh-mwageringel, embray, jhpalmieri, vbraun Merged in:
Authors: Matthias Koeppe Reviewers: John Palmieri
Report Upstream: N/A Work issues:
Branch: 8317c3e (Commits, GitHub, GitLab) Commit: 8317c3eb7729c06aeace618726808d6342fda046
Dependencies: Stopgaps:

Status badges

Description (last modified by mkoeppe)

On the platform local-homebrew-macos defined by tox.ini, running on a macos-latest system as defined in https://help.github.com/en/actions/reference/virtual-environments-for-github-hosted-runners#supported-runners-and-hardware-resources, a branch that includes #27824 (spkg-configure.m4 for python3) leads to the following error with pplpy, as seen in https://github.com/mkoeppe/sage/runs/538432631:

    g++ -sdk macosx clang -bundle -undefined dynamic_lookup -L/Users/runner/runners/2.165.2/work/sage/sage/.tox/local-homebrew-macos-standard/local/lib -Wl,-rpath,/Users/runner/runners/2.165.2/work/sage/sage/.tox/local-homebrew-macos-standard/local/lib -L/Users/runner/runners/2.165.2/work/sage/sage/.tox/local-homebrew-macos-standard/homebrew/opt/readline/lib -L/Users/runner/runners/2.165.2/work/sage/sage/.tox/local-homebrew-macos-standard/homebrew/lib -I/Users/runner/runners/2.165.2/work/sage/sage/.tox/local-homebrew-macos-standard/homebrew/opt/readline/include -I/Users/runner/runners/2.165.2/work/sage/sage/.tox/local-homebrew-macos-standard/homebrew/include build/temp.macosx-10.14-x86_64-3.7/ppl/linear_algebra.o build/temp.macosx-10.14-x86_64-3.7/ppl/ppl_shim.o -lgmp -lgmpxx -lppl -lm -o build/lib.macosx-10.14-x86_64-3.7/ppl/linear_algebra.cpython-37m-darwin.so
    clang: error: unknown argument: '-sdk'
    clang: error: no such file or directory: 'macosx'
    clang: error: no such file or directory: 'clang'
    error: command 'g++' failed with exit status 1
    Running setup.py install for pplpy: finished with status 'error'
Cleaning up...

Same kind of error with scipy, kiwisolver, fpylll.

Full logs can be downloaded at the above link.

To test locally, using #29104 + #27824, remove all python3 from the homebrew in /usr/local and run

tox -e local-homebrew-macos-standard -- V=0 pplpy

With #29417, it is:

tox -e local-homebrew-macos-standard-python3_xcode -- V=0 pplpy

(broken out from #29404)

Change History (79)

comment:1 Changed 16 months ago by dimpase

this needs details on the Python (system MacOS? Homebrew? CPython package?) and on clang (XCode? Homebrew? Other (e.g. conda?))

comment:2 Changed 16 months ago by mkoeppe

  • Description modified (diff)

comment:3 follow-up: Changed 16 months ago by dimpase

what I gather from these links is that Pythons in MacOS are not Homebrew ones.

comment:4 Changed 16 months ago by mkoeppe

  • Cc fbissey gh-mwageringel added
  • Description modified (diff)
  • Summary changed from Fix build errors with pplpy on macos with system python3 to Fix build errors with pplpy, scipy, kiwisolver, fpylll on macos with system python3

comment:5 in reply to: ↑ 3 Changed 16 months ago by mkoeppe

Replying to dimpase:

what I gather from these links is that Pythons in MacOS are not Homebrew ones.

That's right, this is system python3 from /usr/bin

Last edited 16 months ago by mkoeppe (previous) (diff)

comment:6 Changed 16 months ago by mkoeppe

  • Description modified (diff)

comment:7 Changed 16 months ago by mkoeppe

Something seems to get very confused about values from sysconfig as it tries to replace xcrun by g++.

>>> for k, v in sysconfig.get_config_vars().items():
...     if isinstance(v, str) and 'sdk' in v:
...         print(k, v)
... 
BLDSHARED xcrun -sdk macosx clang     -bundle -undefined dynamic_lookup 
CC xcrun -sdk macosx clang    -arch x86_64 
CONFIG_ARGS '-C' '--host=x86_64-apple-darwin' '--build=x86_64-apple-darwin' '--enable-framework=/Applications/Xcode.app/Contents/Developer/Library/Frameworks' '--with-framework-name=Python3' '--with-openssl=/BuildRoot/Library/Caches/com.apple.xbs/Binaries/python3/install/TempContent/Root/Applications/Xcode.app/Contents/Developer/Library/Frameworks/Python3.framework/Versions/3.7' '--enable-ipv6' '--prefix=/Applications/Xcode.app/Contents/Developer/usr' '--with-pymalloc' 'PYTHON_FOR_BUILD=DYLD_FRAMEWORK_PATH=/BuildRoot/Library/Caches/com.apple.xbs/Binaries/python3/install/TempContent/Objects/host /BuildRoot/Library/Caches/com.apple.xbs/Binaries/python3/install/TempContent/Objects/host/python.exe' 'CC=xcrun -sdk macosx clang    -arch x86_64' 'CXX=xcrun -sdk macosx clang++  -arch x86_64' 'CPP=xcrun -sdk macosx clang -E -arch x86_64' 'CFLAGS=-iwithsysroot/System/Library/Frameworks/System.framework/PrivateHeaders -iwithsysroot/Applications/Xcode.app/Contents/Developer/Library/Frameworks/Python3.framework/Versions/3.7/Headers' 'CPPFLAGS=-iwithsysroot/System/Library/Frameworks/System.framework/PrivateHeaders -iwithsysroot/Applications/Xcode.app/Contents/Developer/Library/Frameworks/Python3.framework/Versions/3.7/Headers' 'LIBS=-lSystem' 'LDFLAGS=' 'OBJROOT=/BuildRoot/Library/Caches/com.apple.xbs/Binaries/python3/install/TempContent/Objects' 'SDKROOT=/BuildRoot/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.15.Internal.sdk' 'build_alias=x86_64-apple-darwin' 'host_alias=x86_64-apple-darwin'
CXX xcrun -sdk macosx clang++  -arch x86_64 
LDCXXSHARED xcrun -sdk macosx clang++  -arch x86_64 -bundle -undefined dynamic_lookup
LDSHARED xcrun -sdk macosx clang     -bundle -undefined dynamic_lookup 
LINKCC xcrun -sdk macosx clang    -arch x86_64
MAINCC xcrun -sdk macosx clang    -arch x86_64
SDKROOT /BuildRoot/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.15.Internal.sdk
_OSX_SUPPORT_INITIAL_BLDSHARED xcrun -sdk macosx clang    -arch x86_64 -bundle -undefined dynamic_lookup
_OSX_SUPPORT_INITIAL_LDSHARED xcrun -sdk macosx clang    -arch x86_64 -bundle -undefined dynamic_lookup
_OSX_SUPPORT_INITIAL_CC xcrun -sdk macosx clang    -arch x86_64
_OSX_SUPPORT_INITIAL_CXX xcrun -sdk macosx clang++  -arch x86_64

comment:8 Changed 16 months ago by mkoeppe

It is caused by bizarre code in distutils.unixccompiler.UnixCCompiler.link.

comment:9 Changed 16 months ago by mkoeppe

https://github.com/python/cpython/blob/master/Lib/distutils/unixccompiler.py#L180 with

(Pdb) p self.linker_so
['xcrun', '-sdk', 'macosx', 'clang', '-bundle', '-undefined', 'dynamic_lookup', '-L/Users/mkoeppe/s/sage/sage-rebasing/worktree-algebraic-2018-spring/.tox/local-homebrew-macos-standard/local/lib', '-Wl,-rpath,/Users/mkoeppe/s/sage/sage-rebasing/worktree-algebraic-2018-spring/.tox/local-homebrew-macos-standard/local/lib', '-L/usr/local/opt/readline/lib', '-L/usr/local/lib', '-I/usr/local/opt/readline/include', '-I/usr/local/include']
(Pdb) p self.compiler_cxx
['g++', '-std=gnu++11']

comment:10 Changed 16 months ago by fbissey

Yes, my head hurts when I look at that file. I am fairly sure distros all over have patches for some aspects of it.

From the line it expect some behavior from xcode.

comment:11 Changed 16 months ago by fbissey

Hum

fbissey@itsv-frb15 ~ % xcrun --help
Usage: xcrun [options] <tool name> ... arguments ...

Find and execute the named command line tool from the active developer
directory.

The active developer directory can be set using `xcode-select`, or via the
DEVELOPER_DIR environment variable. See the xcrun and xcode-select manual
pages for more information.

Options:
  -h, --help                  show this help message and exit
  --version                   show the xcrun version
  -v, --verbose               show verbose logging output
  --sdk <sdk name>            find the tool for the given SDK name
  --toolchain <name>          find the tool for the given toolchain
  -l, --log                   show commands to be executed (with --run)
  -f, --find                  only find and print the tool path
  -r, --run                   find and execute the tool (the default behavior)
  -n, --no-cache              do not use the lookup cache
  -k, --kill-cache            invalidate all existing cache entries
  --show-sdk-path             show selected SDK install path
  --show-sdk-version          show selected SDK version
  --show-sdk-build-version    show selected SDK build version
  --show-sdk-platform-path    show selected SDK platform path
  --show-sdk-platform-version show selected SDK platform version

Is it just a stupid -- versus -?

comment:12 Changed 16 months ago by mkoeppe

No, the linked code is really replacing "xcrun" by "g++".

comment:14 Changed 16 months ago by mkoeppe

Each of xcrun -sdk macosx clang, g++, and xcrun -sdk macosx clang++ make sense. But the code tries to mix the first two to get the third, and gets g++ -sdk macosx clang, which makes no sense, obviously.

Last edited 16 months ago by mkoeppe (previous) (diff)

comment:16 Changed 16 months ago by mkoeppe

It's an existing Python issue: https://bugs.python.org/issue8027

comment:17 Changed 16 months ago by mkoeppe

  • Cc embray added

comment:18 Changed 16 months ago by mkoeppe

More precisely, this one: https://bugs.python.org/issue1222585

comment:19 follow-up: Changed 16 months ago by mkoeppe

... open since 2005

comment:20 Changed 16 months ago by mkoeppe

Related previous issue: #17484

comment:21 in reply to: ↑ 19 Changed 16 months ago by fbissey

Replying to mkoeppe:

... open since 2005

Upstream python does have a bad history of compiler/linker support (especially differentiation between C and C++ actually).

comment:22 Changed 16 months ago by mkoeppe

A simple workaround is to clear the CXX environment variable before we call the installation. Then it will build the extension using the compiler configured in python's sysconfig.

comment:23 Changed 16 months ago by fbissey

Hum, OK but only for OSX. The problem is that we set CXX as a c++11 compiler which means CXX may actually be g++ -std=c++11 (or gnu++11 actually) in most case. On OS X, clang++ is c++11 at least by default so we can afford that. On other platforms, we would run into troubles.

Why does CXX includes -std=c++11 rather than it being a separate CPPFLAGS? Because CXX as a whole is defined as a c++11 compiler.

comment:24 Changed 16 months ago by mkoeppe

Our own python3 has g++ -std=c++11 in its sysconfig CXX in that case.

But you are right, for a system python3, we would not be able to assume that the sysconfig CXX is a C++11 compiler.

comment:25 Changed 16 months ago by mkoeppe

So I guess this needs to be figured out at configure time.

comment:26 follow-up: Changed 16 months ago by mkoeppe

A different workaround is to set LDSHARED="$CXX -bundle -undefined dynamic_lookup".

comment:27 Changed 16 months ago by fbissey

That sounds interesting! And it avoids the c++11 mess.

comment:28 Changed 16 months ago by mkoeppe

So, a macOS-specific workaround for all Python packages that use C++ extensions?

comment:29 Changed 16 months ago by fbissey

Unfortunately, pretty much.

comment:30 in reply to: ↑ 26 Changed 16 months ago by mkoeppe

Interesting is also this test: https://github.com/python/cpython/blob/e42b705188271da108de42b55d9344642170aa2b/Lib/distutils/tests/test_unixccompiler.py#L105 which corresponds to https://bugs.python.org/issue18080. The code added in this issue is unfortunately made ineffective by the fact that in Apple's installation, cc = "xcrun -sdk macosx clang -arch x86_64 " and ldshared = "xcrun -sdk macosx clang -bundle -undefined dynamic_lookup ", i.e., ldshared.startswith(cc) is False.

comment:31 follow-up: Changed 16 months ago by mkoeppe

A candidate for a portable solution, to be applied to all Python packages that build C++ extensions would be:

LDSHARED=$(/usr/bin/python -c 'import sysconfig; print(sysconfig.get_config_var("LDCXXSHARED"))')

comment:32 Changed 16 months ago by mkoeppe

With this, packages would still compile with CXX (which would include the C++11 flags if needed), but link with the C++ linker known to sysconfig.

comment:33 in reply to: ↑ 31 Changed 16 months ago by fbissey

Replying to mkoeppe:

A candidate for a portable solution, to be applied to all Python packages that build C++ extensions would be:

LDSHARED=$(/usr/bin/python -c 'import sysconfig; print(sysconfig.get_config_var("LDCXXSHARED"))')

I don't like the /usr/bin/python bit, but I am sure we can replace that by something appropriate. That sounds like a good idea and now it needs to be tested.

comment:34 Changed 16 months ago by mkoeppe

Right, of course it would be LDSHARED=$(sage-python23 -c 'import sysconfig; print(sysconfig.get_config_var("LDCXXSHARED"))').

comment:35 Changed 16 months ago by mkoeppe

  • Branch set to u/mkoeppe/fix_build_errors_with_pplpy__scipy__kiwisolver__fpylll_on_macos_with_system_python3

comment:36 Changed 16 months ago by mkoeppe

  • Commit set to 4541e189ee189c554512c2948aba7bdea6b02629

This did not work after all, but I have found a solution that seems to work and is reasonably clean.


New commits:

4541e18src/bin/sage-env: Set LDSHARED when CXX is set

comment:37 Changed 16 months ago by mkoeppe

Setting this unconditionally in sage-env rather than in package build scripts -- to make sure that these settings are in place even when a user does a sage -pip install of some random package.

comment:38 Changed 16 months ago by mkoeppe

  • Authors set to Matthias Koeppe

comment:39 Changed 16 months ago by fbissey

Looks OK to me. I guess you have some bots testing it out.

comment:41 Changed 16 months ago by mkoeppe

  • Status changed from new to needs_review

comment:42 Changed 16 months ago by mkoeppe

  • Status changed from needs_review to needs_work

This breaks matplotlib via numpy unfortunately

comment:43 Changed 16 months ago by mkoeppe

        from numpy.core._multiarray_umath import (
    ImportError: /sage/local/lib/python3.7/site-packages/numpy/core/_multiarray_umath.cpython-37m-x86_64-linux-gnu.so: undefined symbol: __cpu_model

comment:44 Changed 16 months ago by git

  • Commit changed from 4541e189ee189c554512c2948aba7bdea6b02629 to 747297132ccf36b1c610ccafbef984a403fc39e7

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

7472971build/pkgs/numpy/spkg-install.in: Unset LDSHARED

comment:45 Changed 16 months ago by mkoeppe

  • Status changed from needs_work to needs_review

comment:46 Changed 16 months ago by isuruf

  • Status changed from needs_review to needs_work

This is dropping -pthread on linux.

comment:47 follow-up: Changed 16 months ago by isuruf

Original issue is because the logic at https://github.com/python/cpython/blob/8510f430781118d9b603c3a2f06945d6ebc5fe42/Lib/distutils/sysconfig.py#L204-L205 doesn't get triggered with,

CC xcrun -sdk macosx clang    -arch x86_64
LDSHARED xcrun -sdk macosx clang     -bundle -undefined dynamic_lookup

comment:48 Changed 16 months ago by mkoeppe

Help with this ticket is welcome!

comment:49 Changed 16 months ago by mkoeppe

  • Priority changed from major to critical

comment:50 in reply to: ↑ 47 Changed 16 months ago by dimpase

Replying to isuruf:

Original issue is because the logic at https://github.com/python/cpython/blob/8510f430781118d9b603c3a2f06945d6ebc5fe42/Lib/distutils/sysconfig.py#L204-L205 doesn't get triggered with,

CC xcrun -sdk macosx clang    -arch x86_64
LDSHARED xcrun -sdk macosx clang     -bundle -undefined dynamic_lookup

I don't quite understand this comment. Should it be CC=... etc? Anyhow, we can propose an upstream patch...

comment:51 Changed 16 months ago by isuruf

https://github.com/python/cpython/blob/8510f430781118d9b603c3a2f06945d6ebc5fe42/Lib/distutils/sysconfig.py#L204-L205 checks that LDSHARED starts with the old CC and if so, old CC is replaced with the new CC.

If LDSHARED was xcrun -sdk macosx clang -arch x86_64 -bundle -undefined dynamic_lookup, then setting CC=clang would give you, clang -bundle -undefined dynamic_lookup, but at the moment it is not.

comment:52 Changed 16 months ago by mkoeppe

  • Description modified (diff)

comment:53 Changed 16 months ago by mkoeppe

  • Cc jhpalmieri added

comment:54 Changed 16 months ago by isuruf

  • Authors changed from Matthias Koeppe to Matthias Koeppe, Isuru Fernando
  • Branch changed from u/mkoeppe/fix_build_errors_with_pplpy__scipy__kiwisolver__fpylll_on_macos_with_system_python3 to u/isuruf/fix_build_errors_with_pplpy__scipy__kiwisolver__fpylll_on_macos_with_system_python3
  • Commit changed from 747297132ccf36b1c610ccafbef984a403fc39e7 to bcb753409f879151616cb022be8a35247f4be2e0
  • Status changed from needs_work to needs_review

New commits:

bcb7534Add -pthread to LDSHARED

comment:55 Changed 16 months ago by mkoeppe

Fails on ubuntu-xenial-standard (https://github.com/mkoeppe/sage/runs/552215553):

  ImportError: /sage/local/lib/python3.7/site-packages/numpy/core/_multiarray_umath.cpython-37m-x86_64-linux-gnu.so: undefined symbol: __cpu_model

comment:56 Changed 16 months ago by mkoeppe

  • Status changed from needs_review to needs_work

comment:57 follow-up: Changed 16 months ago by isuruf

It looks like on ubuntu, LDSHARED has -Wl,-Bsymbolic-functions which we need to include. Shall we only set LDSHARED in OSX?

comment:58 in reply to: ↑ 57 Changed 16 months ago by mkoeppe

Replying to isuruf:

Shall we only set LDSHARED in OSX?

Probably better, yes

comment:59 Changed 16 months ago by git

  • Commit changed from bcb753409f879151616cb022be8a35247f4be2e0 to e4056f05b37a5bae7ceca18992ee91a502089259

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

e4056f0Set LDSHARED only on OSX

comment:60 Changed 16 months ago by isuruf

  • Status changed from needs_work to needs_review

comment:61 Changed 16 months ago by mkoeppe

  • Branch changed from u/isuruf/fix_build_errors_with_pplpy__scipy__kiwisolver__fpylll_on_macos_with_system_python3 to u/mkoeppe/fix_build_errors_with_pplpy__scipy__kiwisolver__fpylll_on_macos_with_system_python3

comment:62 Changed 16 months ago by mkoeppe

  • Commit changed from e4056f05b37a5bae7ceca18992ee91a502089259 to 96a599c5ff3802bd77f63688d859aa689c3f5fe1

rebased on 9.1.beta9


New commits:

7a6238esrc/bin/sage-env: Set LDSHARED when CXX is set
cbe7a1ebuild/pkgs/numpy/spkg-install.in: Unset LDSHARED
089d2a2Add -pthread to LDSHARED
96a599cSet LDSHARED only on OSX

comment:63 Changed 16 months ago by mkoeppe

On local-homebrew-macos-python3_pythonorg-minimal(https://github.com/mkoeppe/sage/runs/557674691):

sage -t src/sage/repl/ipython_extension.py
**********************************************************************
File "src/sage/repl/ipython_extension.py", line 385, in sage.repl.ipython_extension.SageMagics.fortran
Failed example:
...
RuntimeError: failed to compile Fortran code:
    b'Could not locate executable g++ -std=gnu++11 -pthread -bundle -undefined dynamic_lookup\nIn file included from 

comment:64 Changed 16 months ago by mkoeppe

  • Status changed from needs_review to needs_work

comment:65 Changed 16 months ago by mkoeppe

Also

sage -t src/sage/interfaces/gap.py  # 1 doctest failed
sage -t src/sage/misc/inline_fortran.py  # 3 doctests failed
sage -t src/sage/misc/persist.pyx  # 2 doctests failed

comment:66 Changed 16 months ago by git

  • Commit changed from 96a599c5ff3802bd77f63688d859aa689c3f5fe1 to 8317c3eb7729c06aeace618726808d6342fda046

Branch pushed to git repo; I updated commit sha1. This was a forced push. New commits:

f721740build/pkgs/python3/spkg-configure.m4: Also check whether C++ extensions can be built
8317c3eUndo #21175: Set ARCHFLAGS only when compiling Perl modules

comment:67 Changed 16 months ago by mkoeppe

  • Status changed from needs_work to needs_review

Started again from scratch. Turns out I broke it 4 years ago in #21175 by setting ARCHFLAGS. This interacts in a bizarre way with the bizarre code discussed above.

comment:68 Changed 16 months ago by mkoeppe

  • Authors changed from Matthias Koeppe, Isuru Fernando to Matthias Koeppe

comment:70 follow-up: Changed 16 months ago by jhpalmieri

This works for me, but I don't understand the changes in build/pkgs/python3/spkg-configure.m4.

comment:71 follow-up: Changed 16 months ago by jhpalmieri

So if someone else wants to review it, I am happy to give some fraction of a positive review.

comment:72 in reply to: ↑ 70 Changed 16 months ago by mkoeppe

Replying to jhpalmieri:

I don't understand the changes in build/pkgs/python3/spkg-configure.m4.

There was already a test that the system python (in the venv) is able to build a C extension. The change tightens this check by imposing the configured CC (and CXX) values -- because this is what the actual build will be running. It also adds the same test for building a C++ 11 extension.

comment:73 in reply to: ↑ 71 Changed 16 months ago by mkoeppe

Replying to jhpalmieri:

some fraction of a positive review.

100% thanks already

comment:74 Changed 16 months ago by mkoeppe

Let's also get this one into the next beta please

comment:75 Changed 16 months ago by mkoeppe

  • Cc vbraun added

comment:76 Changed 16 months ago by mkoeppe

  • Priority changed from critical to blocker

comment:77 Changed 16 months ago by jhpalmieri

  • Reviewers set to John Palmieri
  • Status changed from needs_review to positive_review

Okay, let's merge it. I can't get polymake to build with or without these changes, and the changes make sense.

Re polymake, here is the error:

ninja: Entering directory `build/Opt'
[1/1] GENERATE /Users/palmieri/Desktop/Sage_stuff/sage_builds/PYTHON3/sage-9.1.beta9/local/var/tmp/sage/build/polymake-3.4/src/build/targets.ninja
FAILED: /Users/palmieri/Desktop/Sage_stuff/sage_builds/PYTHON3/sage-9.1.beta9/local/var/tmp/sage/build/polymake-3.4/src/build/targets.ninja 
/usr/bin/perl /Users/palmieri/Desktop/Sage_stuff/sage_builds/PYTHON3/sage-9.1.beta9/local/var/tmp/sage/build/polymake-3.4/src/support/generate_ninja_targets.pl /Users/palmieri/Desktop/Sage_stuff/sage_builds/PYTHON3/sage-9.1.beta9/local/var/tmp/sage/build/polymake-3.4/src/build/targets.ninja /Users/palmieri/Desktop/Sage_stuff/sage_builds/PYTHON3/sage-9.1.beta9/local/var/tmp/sage/build/polymake-3.4/src /Users/palmieri/Desktop/Sage_stuff/sage_builds/PYTHON3/sage-9.1.beta9/local/var/tmp/sage/build/polymake-3.4/src/build/config.ninja
Can't locate JSON.pm in @INC (you may need to install the JSON module) (@INC contains: /Users/palmieri/Desktop/Sage_stuff/sage_builds/PYTHON3/sage-9.1.beta9/local/lib/perl5/darwin-thread-multi-2level /Users/palmieri/Desktop/Sage_stuff/sage_builds/PYTHON3/sage-9.1.beta9/local/lib/perl5 /Library/Perl/5.18/darwin-thread-multi-2level /Library/Perl/5.18 /Network/Library/Perl/5.18/darwin-thread-multi-2level /Network/Library/Perl/5.18 /Library/Perl/Updates/5.18.4 /System/Library/Perl/5.18/darwin-thread-multi-2level /System/Library/Perl/5.18 /System/Library/Perl/Extras/5.18/darwin-thread-multi-2level /System/Library/Perl/Extras/5.18 .) at /Users/palmieri/Desktop/Sage_stuff/sage_builds/PYTHON3/sage-9.1.beta9/local/var/tmp/sage/build/polymake-3.4/src/support/generate_cpperl_modules.pl line 22.
BEGIN failed--compilation aborted at /Users/palmieri/Desktop/Sage_stuff/sage_builds/PYTHON3/sage-9.1.beta9/local/var/tmp/sage/build/polymake-3.4/src/support/generate_cpperl_modules.pl line 22.
ninja: error: rebuilding 'build.ninja': subcommand failed
make[2]: *** [all] Error 1

It's probably the old problem of not having the right perl modules present and Sage's polymake build system failing to recognize that. The instructions in polymake's SPKG.txt are no longer valid.

In any case, the polymake problems should be dealt with at #29054.

comment:78 Changed 16 months ago by mkoeppe

Thanks. Yes, polymake will take more work.

comment:79 Changed 16 months ago by vbraun

  • Branch changed from u/mkoeppe/fix_build_errors_with_pplpy__scipy__kiwisolver__fpylll_on_macos_with_system_python3 to 8317c3eb7729c06aeace618726808d6342fda046
  • Resolution set to fixed
  • Status changed from positive_review to closed
Note: See TracTickets for help on using tickets.