Any interest in making building from source on Mac more robust?

[Mike Wirth]

<David Roe suggested that I post this here, as well as having done so on zulipchat>

Sage newbie. here, but long term Mac, etc., user and developer. Did serious early work with algebraic manipulation system, Macsyma, including doing internal mods in Lisp for 2D display of math expressions (pre-Latex). Especially interested in the manifolds package for tensor calculus. 

My primary Sage installation is on an old MacBook Pro (2014-vintage, 11,3 model) but running current macOS 15..3.1, patched with OCLP 2.2.0, built from downloaded binaries. Since I expect to want to inspect and possibly modify Sage internals, I tried building from source on this machine. Very frustrating. Despite Dima's excellent repeated help, wasn't able to successfully complete the build. Encountered a circular set of errors, dealing with Python and pip versions, certificates, etc., Put the effort on the back burner pending a better understanding of the issues.

However, using this MacBook Pro with the Parallels Desktop system and a Ubuntu 22.4 VM, I did complete a from-source build. And installed Ubuntu 24.1 LTS directly on another MacBook Pro (9,3) and a Sage from-source build there. So now I'm set to explore Sage for my purposes.

But I still want to be able to do a clean build from source on current macOS versions. Are there developers in this community with similar interests? I would be interested in collaborating with you on making the build process on macOS more robust. Feel free to respond to this post or directly to me to see if there's a practical path forward.

Mike
Silicon Valley

[Volker Braun]

For the record, we do have a macOS buildbot that compiles every version we release (successfully except for giac, see related thread) at http://build.sagemath.org/#/builders/16

[Kwankyu Lee]

But I still want to be able to do a clean build from source on current macOS versions. Are there developers in this community with similar interests? I would be interested in collaborating with you on making the build process on macOS more robust. 

My main machines are all macOS. I never thought building Sage on macOS is not robust, though there are transient hiccups once in a while, of course.

I am now building the latest release on both macOS 15.3.1 with intel chip and with M4 chip from scratch.

Would you try again on your machine? I may help you though I am not savvy as much as Dima.

This is the usual steps:

git checkout develop

git pull

make distclean && ./bootstrap && ./configure && make && sage -tp --all  

 

[Kwankyu Lee]

Ah I forgot to mention:

brew upgrade

and

source .homebrew-build-env

before "make ..."

[dim...@gmail.com]

Dear all,

To summarise what I found qua Mike's installation issues:

It seems that macOS/XCode stopped providing Pythons what are good enough to use to
install Sage from source, as their networking is broken in some way
which make it impossible to fetch packages for
installation. The main symptome looks like an SSL cert check failure
while fetching pip spkg tarball by sage_bootstrap/download/transfer.py:

[pip-24.2] Attempting to download package pip-24.2-py3-none-any.whl from mirrors
[pip-24.2] https://github.com/sagemath/sage/releases/download/10.6/pip-24.2-py3-none-any.whl
[pip-24.2] [xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx]
[pip-24.2] ERROR [transfer|run:135]: [Errno socket error] [SSL: CERTIFICATE_VERIFY_FAILED] certificate verify failed: unable to get local issuer certificate (_ssl.c:992)

[....]

[pip-24.2] File "/Library/Frameworks/Python.framework/Versions/3.11/lib/python3.11/ssl.py", line 1346, in do_handshake
[pip-24.2] self._sslobj.do_handshake()
[pip-24.2] ssl.SSLCertVerificationError: [SSL: CERTIFICATE_VERIFY_FAILED] certificate verify failed: unable to get local issuer certificate (_ssl.c:992)
[pip-24.2]
[pip-24.2] The above exception was the direct cause of the following exception:
[pip-24.2]
[pip-24.2] Traceback (most recent call last):
[pip-24.2] File "/Users/mike/sage/build/bin/../sage_bootstrap/tarball.py", line 185, in download
[pip-24.2] Download(url, destination).run()
[pip-24.2] File "/Users/mike/sage/build/bin/../sage_bootstrap/download/transfer.py", line 137, in run
[pip-24.2] raise error
[pip-24.2] File "/Users/mike/sage/build/bin/../sage_bootstrap/download/transfer.py", line 128, in run
[pip-24.2] filename, info = opener.retrieve(
[pip-24.2] ^^^^^^^^^^^^^^^^
[pip-24.2] File "/Library/Frameworks/Python.framework/Versions/3.11/lib/python3.11/urllib/request.py", line 1821, in retrieve
[pip-24.2] fp = self.open(url, data)
[pip-24.2] ^^^^^^^^^^^^^^^^^^^^
[pip-24.2] File "/Library/Frameworks/Python.framework/Versions/3.11/lib/python3.11/urllib/request.py", line 1793, in open
[pip-24.2] raise OSError('socket error', msg) from msg
[pip-24.2] OSError: [Errno socket error] [SSL: CERTIFICATE_VERIFY_FAILED] certificate verify failed: unable to get local issuer certificate (_ssl.c:992)

These capabilities are not tested by ./configure

The Python I'm talking about is not to be confused with tests to use "system" Python to run sagelib,
these tests are more detailed, in particular availability of Python modules

sqlite3, ctypes, math, hashlib, socket, zlib, ssl, ensurepip

is checked. I don't know whether a modern (Troyan horse) Python from Apple
lacks some of these modules, or perhaps some of these modules are
broken.

----------------------------------------------------------------------------------

To me, the right course of action is to purge from Sage its
(half-broken anyway) capabilities to build Python (as on macOS there is an abundance of Pythons either
from python.org or from Homebrew, and building Python is tricky do to
due to SSL issues); then all this mess would not have arisen in the 1st place.

And, sorry for sounding like a broken record: building and providing Python should be
left to experts, are we are not experts in this.

Dima

> --
> You received this message because you are subscribed to the Google Groups "sage-devel" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+...@googlegroups.com.
> To view this discussion visit https://groups.google.com/d/msgid/sage-devel/CAFpc19Xw1Nbn87AooOpRp9vwD168UpcZOCMUykLv0O9FLUbYhA%40mail.gmail.com.

[Mike Wirth]

Thank you, Volker, for that proof of viability of building Sage on Apple silicon (an M2 Mini) and to Kwankyu on both an M4 and Intel, all with macOS 15.3.1 (I assume).  I would be happy to try again as suggested.  But I expect I need to do some cleaning of accumulated crud on my system first to eliminate possible stumbling blocks.  In that regard, I would appreciate any info you could provide on the following:

• Pre-existing Python and pip installations, whether part of std macOS "Sequoia" 15.3.1 or otherwise.
• Any venv environments outside those initiated inside the build.
• Expected Homebrew release level
• Any changes to the list of suggested brew-installed packages (either from the Installation Guide web pages or the README file in the repo)
• Installed certificates for secure downloads during the build process or any proxy issues. (I don't use any proxy.)
• Any special considerations for the environment variables, esp. PATH?
• <anything else I missed Dima?>

Since I'm on a high-speed Internet connection(1Gbps fiber), but with a slow(!) Mac, the easiest way to produce a clean repo is to wipe the old one and download a new copy via git.   And, yes,. I'm patient enough to repeat the configure/make process multiple times to sort out the issues for other Mac users with similar configurations.

TIA,

Mike

PS: While I am using a patched macOS (OCLP 2.2.0), I'm not suspicious of that creating a problem; it's patches on my MacBook Pro 11,3 is limited to graphics card drivers and the WiFi driver.

--

You received this message because you are subscribed to the Google Groups "sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+...@googlegroups.com.

To view this discussion visit https://groups.google.com/d/msgid/sage-devel/3a9b409e-44cc-44e1-8276-5073ecbe713bn%40googlegroups.com.

[Kwankyu Lee]

https://github.com/sagemath/sage/pull/39571 is needed for successful build with the latest release. 

On Saturday, February 22, 2025 at 10:27:40 PM UTC+9 mwi...@gmail.com wrote:

Thank you, Volker, for that proof of viability of building Sage on Apple silicon (an M2 Mini) and to Kwankyu on both an M4 and Intel, all with macOS 15.3.1 (I assume).  I would be happy to try again as suggested.  But I expect I need to do some cleaning of accumulated crud on my system first to eliminate possible stumbling blocks.  In that regard, I would appreciate any info you could provide on the following:

• Pre-existing Python and pip installations, whether part of std macOS "Sequoia" 15.3.1 or otherwise.
• Any venv environments outside those initiated inside the build.
• Expected Homebrew release level
• Any changes to the list of suggested brew-installed packages (either from the Installation Guide web pages or the README file in the repo)
• Installed certificates for secure downloads during the build process or any proxy issues. (I don't use any proxy.)
• Any special considerations for the environment variables, esp. PATH

Instead you try first, and then report where it fails and provide the logs.

[Mike Wirth]

Thanks, Kwankyu,,

I'll take the incremental testing approach.  As a first set of questions:

• On the Install from Source Code page, the "macOS package installation" paragraph advises the installation of a long list of binary packages with Homebrew, e.g., 
  

1. brew install bdw-gc boost bzip2 cddlib cmake curl ecl flint fplll freetype...

I presume that all the listed packages should be installed, if at all possible.  Correct?

• Such pkg installations often issue cautions and advice, e.,g.

For compilers to find libffi you may need to set:

  export LDFLAGS="-L/usr/local/opt/libffi/lib"

  export CPPFLAGS="-I/usr/local/opt/libffi/include"

For pkg-config to find libffi you may need to set:

  export PKG_CONFIG_PATH="/usr/local/opt/libffi/lib/pkgconfig" ==> libiconv

To what extent should the environment variables, etc., be modified in order to follow this advice?

• If I understand correctly, system binaries which fail to be installed during this preparation phase will be replaced by source from inside the repo (rts files?) which will be built during the compile phase (at the expense of increased build time).  Correct?

The last question may provide an answer to my other question: How is it possible to do just the configure/make steps without the preparatory work to instal system binaries?  At worst case everything will be built on the fly.

Thanks for any responses and further illumination,

Mike

 

--
You received this message because you are subscribed to the Google Groups "sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+...@googlegroups.com.

To view this discussion visit https://groups.google.com/d/msgid/sage-devel/70897332-0bac-4327-9138-4e12d94cd29fn%40googlegroups.com.

[Kwankyu Lee]

Is your branch on the PR branch of https://github.com/sagemath/sage/pull/39571 ? It should be for the current release.

I'll take the incremental testing approach.  As a first set of questions:

• On the Install from Source Code page, the "macOS package installation" paragraph advises the installation of a long list of binary packages with Homebrew, e.g., 
  

1. 1. brew install bdw-gc boost bzip2 cddlib cmake curl ecl flint fplll freetype...

I presume that all the listed packages should be installed, if at all possible.  Correct?

They are recommended (to decrease the time building sage), but not required.

 

• Such pkg installations often issue cautions and advice, e.,g.

For compilers to find libffi you may need to set:

  export LDFLAGS="-L/usr/local/opt/libffi/lib"

  export CPPFLAGS="-I/usr/local/opt/libffi/include"

For pkg-config to find libffi you may need to set:

  export PKG_CONFIG_PATH="/usr/local/opt/libffi/lib/pkgconfig" ==> libiconv

To what extent should the environment variables, etc., be modified in order to follow this advice?

Let's ignore these now. Just install as many of the recommended system packages as possible, and ignore others that fail.

• If I understand correctly, system binaries which fail to be installed during this preparation phase will be replaced by source from inside the repo (rts files?) which will be built during the compile phase (at the expense of increased build time).  Correct?

Yes

 

The last question may provide an answer to my other question: How is it possible to do just the configure/make steps without the preparatory work to instal system binaries?  At worst case everything will be built on the fly.

Without the preparatory work (meaning "brew ..."), sage will build all necessary packages from source and install them into "SAGE_ROOT/local/" where SAGE_ROOT is where you cloned sage repo.

Leave checks for:

[O] brew upgrade

[O] brew install ...

[O] gh pr checkout 39571 (and you are on https://github.com/sagemath/sage/pull/39571)

[O] source .homebrew-build-env

[X] make distclean 

[X] ./bootstrap 

[X] ./configure 

[X] make

[X] sage -tp --all  

[Marc Culler]

I don't see any connection between:

* SSL cert failures when using  python provided by "macOS/XCode"

* The existence of Sage's python spkg

I have been seeing those cert failures for years now.  I have never had any trouble with Sage's python spkg.  It has always built cleanly for me.  So this not only sounds like a broken record, it has nothing to do with the issue at hand.

There have been many times when I have had to download a Sage file with my browser and move it into the "updtream" directory due to SSL cert failures.  And that has literally been true for years.

- Marc

[Dima Pasechnik]

On 25 February 2025 07:17:59 GMT-06:00, Marc Culler <marc....@gmail.com> wrote:
>I don't see any connection between:
>
>* SSL cert failures when using python provided by "macOS/XCode"
>* The existence of Sage's python spkg
>
>I have been seeing those cert failures for years now. I have never had any
>trouble with Sage's python spkg. It has always built cleanly for me. So
>this not only sounds like a broken record, it has nothing to do with the
>issue at hand.
>
>There have been many times when I have had to download a Sage file with my
>browser and move it into the "updtream" directory due to SSL cert
>failures. And that has literally been true for years.
>

this is precisely due to the cert failures caused by the broken macOS's python.

Does not happen with a good Python install.

[Marc Culler]

On Tue, Feb 25, 2025 at 9:52 AM Dima Pasechnik <dim...@gmail.com> wrote:

this is precisely due to the cert failures caused by the broken macOS's python.

Does not happen with a good Python install.

I am sorry, but that statement is false.  See the example below where an SSL Certification error occurs with Python 3.13.1 from python.org running in a venv with certifi-2025.1.31 installed in the venv.  The Apple /usr/binpython3 was not involved and the python.org installation of

python is a "good python install".

- Marc

 

[patch-2.7.6] Attempting to download from https://ftp.gnu.org/gnu/patch/patch-2.7.6.tar.gz
[patch-2.7.6] [xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx]
[patch-2.7.6] ERROR [transfer|run:135]: [Errno socket error] [SSL: CERTIFICATE_VERIFY_FAILED] certificate verify failed: unable to get local issuer certificate (_ssl.c:1018)
[patch-2.7.6] Traceback (most recent call last):
[patch-2.7.6]   File "/Library/Frameworks/Python.framework/Versions/3.13/lib/python3.13/urllib/request.py", line 1778, in open
[patch-2.7.6]     return getattr(self, name)(url)
[patch-2.7.6]            ~~~~~~~~~~~~~~~~~~~^^^^^
[patch-2.7.6]   File "/Library/Frameworks/Python.framework/Versions/3.13/lib/python3.13/urllib/request.py", line 1992, in open_https
[patch-2.7.6]     return self._open_generic_http(self._https_connection, url, data)
[patch-2.7.6]            ~~~~~~~~~~~~~~~~~~~~~~~^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
[patch-2.7.6]   File "/Library/Frameworks/Python.framework/Versions/3.13/lib/python3.13/urllib/request.py", line 1933, in _open_generic_http
[patch-2.7.6]     http_conn.request("GET", selector, headers=headers)
[patch-2.7.6]     ~~~~~~~~~~~~~~~~~^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
[patch-2.7.6]   File "/Library/Frameworks/Python.framework/Versions/3.13/lib/python3.13/http/client.py", line 1336, in request
[patch-2.7.6]     self._send_request(method, url, body, headers, encode_chunked)
[patch-2.7.6]     ~~~~~~~~~~~~~~~~~~^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
[patch-2.7.6]   File "/Library/Frameworks/Python.framework/Versions/3.13/lib/python3.13/http/client.py", line 1382, in _send_request
[patch-2.7.6]     self.endheaders(body, encode_chunked=encode_chunked)
[patch-2.7.6]     ~~~~~~~~~~~~~~~^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
[patch-2.7.6]   File "/Library/Frameworks/Python.framework/Versions/3.13/lib/python3.13/http/client.py", line 1331, in endheaders
[patch-2.7.6]     self._send_output(message_body, encode_chunked=encode_chunked)
[patch-2.7.6]     ~~~~~~~~~~~~~~~~~^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
[patch-2.7.6]   File "/Library/Frameworks/Python.framework/Versions/3.13/lib/python3.13/http/client.py", line 1091, in _send_output
[patch-2.7.6]     self.send(msg)
[patch-2.7.6]     ~~~~~~~~~^^^^^
[patch-2.7.6]   File "/Library/Frameworks/Python.framework/Versions/3.13/lib/python3.13/http/client.py", line 1035, in send
[patch-2.7.6]     self.connect()
[patch-2.7.6]     ~~~~~~~~~~~~^^
[patch-2.7.6]   File "/Library/Frameworks/Python.framework/Versions/3.13/lib/python3.13/http/client.py", line 1477, in connect
[patch-2.7.6]     self.sock = self._context.wrap_socket(self.sock,
[patch-2.7.6]                 ~~~~~~~~~~~~~~~~~~~~~~~~~^^^^^^^^^^^
[patch-2.7.6]                                           server_hostname=server_hostname)
[patch-2.7.6]                                           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
[patch-2.7.6]   File "/Library/Frameworks/Python.framework/Versions/3.13/lib/python3.13/ssl.py", line 455, in wrap_socket
[patch-2.7.6]     return self.sslsocket_class._create(
[patch-2.7.6]            ~~~~~~~~~~~~~~~~~~~~~~~~~~~~^
[patch-2.7.6]         sock=sock,
[patch-2.7.6]         ^^^^^^^^^^
[patch-2.7.6]     ...<5 lines>...
[patch-2.7.6]         session=session
[patch-2.7.6]         ^^^^^^^^^^^^^^^
[patch-2.7.6]     )
[patch-2.7.6]     ^
[patch-2.7.6]   File "/Library/Frameworks/Python.framework/Versions/3.13/lib/python3.13/ssl.py", line 1076, in _create
[patch-2.7.6]     self.do_handshake()
[patch-2.7.6]     ~~~~~~~~~~~~~~~~~^^
[patch-2.7.6]   File "/Library/Frameworks/Python.framework/Versions/3.13/lib/python3.13/ssl.py", line 1372, in do_handshake
[patch-2.7.6]     self._sslobj.do_handshake()
[patch-2.7.6]     ~~~~~~~~~~~~~~~~~~~~~~~~~^^
[patch-2.7.6] ssl.SSLCertVerificationError: [SSL: CERTIFICATE_VERIFY_FAILED] certificate verify failed: unable to get local issuer certificate (_ssl.c:1018)

[Marc Culler]

By the way, there is a simple workaround for the certification verification errors, which is to disable  certificate verification.  Since Sage checks the SHA256 hash of each file it downloads, I don't think this is a serious security risk.  Here is a 2-line patch which does that:

diff --git a/build/sage_bootstrap/download/transfer.py b/build/sage_bootstrap/download/transfer.py
index ae139c391b1..3c6a877288f 100644
--- a/build/sage_bootstrap/download/transfer.py
+++ b/build/sage_bootstrap/download/transfer.py
@@ -18,6 +18,8 @@ Download files from the internet
 import sys
 import logging
 log = logging.getLogger()
+import ssl
+ssl._create_default_https_context = ssl._create_unverified_context
 
 from sage_bootstrap.stdio import flush
 from sage_bootstrap.compat import urllib

- Marc

[Mike Wirth]

<Sent again with a doc link rather than attaching the full 30MB>

On Tue, Feb 25, 2025 at 11:54 PM Mike Wirth <mwi...@gmail.com> wrote:

Hi all,

Responding to a suggestion to not pay attention to binary pkgs that Homebrew failed to install, and pressing forward with the build, I did so. Took a long(!) time on this wimpy MacBook Pro 9,2 from a decade ago (but running the latest, clean install of macOS 15.3.1 Sequoia, patched with OCLP 2.2.0).  As I said:

• I started with the Sage repo updated to the develop/10.6.beta7 commit of Feb 21
• The build did complete.
• It took a lo....ng time.
• The dreaded "bad certificates" issue didn't show up (which I attribute to an earlier attempt in which I did a download from python.org install of python 13.3.2, which explicitly asked to update certificates and I permitted -- causing no ene of trouble before).
  
• I've attached a zip file containing the full content of the logs folder resulting from the build with lots(!) of reports of pkgs that had to be built.
• The zip file also contains the full console transcript of the source download, configure and make process.
• The last few lines show my attempt to start the app and its crash on a "missing package".

Look forward to people's comments and suggestions; hope this series of build experiments are ultimately useful to the community.

Mike

Link to zip file: https://drive.google.com/file/d/19rhrV4OGKkN-XbpWBJNr78cK8gzROAYc/view?usp=share_link

 

[Kwankyu Lee]

You are not on the branch of the PR: https://github.com/sagemath/sage/pull/39571 Are you?

[Kwankyu Lee]

To be on the PR branch, execute

git fetch upstream pull/35971/head:pr-35971

git checkout pr-35971

after you have already set the github repo sagemath/sage as "upstream" remote.

[Kwankyu Lee]

Sorry it is "39571" everywhere in my instructions.