This situation with OpenSSL is frustrating for you and for many Sage users
on macOS and the developers are equally frustrated. Things will hopefully
improve dramatically with the release of OpenSSL 3.0 which comes under
an Apache license compatible with the GPL, so that Sage will be able to
distribute it. Currently OpenSSL 3.0.0alpha9 is out... Progress on this front
is tracked on the Sage side at
In the meanwhile, here are some possible ways forward.
The best is if you can fix Sage's Python in place by sticking in
the appropriate SSL capability for it using the
That script is currently provided to fix Python 3.7, which will work
with Sage 9.0 and 9.1; not yet with 9.2 which is based on Python 3.8.
Otherwise, I would either install Sage via Conda or build it from source,
and then in your existing app, rename the sage executable (allowing
to restore it later if needed), and put a symbolic link to an SSL-enabled
Sage (either installed via Conda or built from source) in its place.
To install Sage on macOS is via Conda, follow this guide:
or make your own mix of that guide and the hints on the
To install from source, get the sources from the
Once you have extracted the source tarball, prepare as follows:
place the extracted folder where you want it (Sage stops
working if moved after using it, so better put it
where you want it before building; if you move Sage
afterwards, you need to build it again)
open a terminal and change to the extracted Sage folder
Then, if you also have Homebrew, run the following:
source .homebrew-build-env
(There has been a lot of effort to make Sage use as many as possible
of Homebrew's packages to save building many components.
Not sure to what extent MacPort packages can be used.)
Decide on how many jobs to run in parallel while building, for example
to run 1, 4, 8 or 16 jobs in parallel while building, use
MAKE='make -j1'
MAKE='make -j4'
MAKE='make -j8'
MAKE='make -j16'
Then configure:
make configure
./configure
Once you have run the configure step, check in the file config.log
what it says on what it has decided regarding Python: build its own,
use the one from MacPorts, use a different one?
Possibly you can tell it exactly which Python to use, using something like:
./configure --with-python=...
(someone else would have to confirm).
If it looks like it is going to use the Python you want, great.
Otherwise, run configure again enabling openssl.
./configure --enable-openssl
Check in config.log if it detected your existing openssl;
otherwise build OpenSSL first to make sure an SSL-enabled
Python will be built.
make -s V=0 openssl
Then build the rest of Sage:
make -s V=0
Edit to address original poster's comment after the answer above.
The Sage build system, despite all its quirks, works in a lot of situations,
which is no small feat.
Improvements have always been welcome. Along the years, tremendous effort
has gone into streamlining the build process, making it more modular,
packaging Sage for various distributions.
There was a time when the Sage build system could not handle Fink or MacPorts
or Homebrew being around; users had to tweak their PATH or rename
their /opt/local or /usr/local while building Sage.
To make life easier, the build system was made to ignore the Fink and MacPorts
directories itself. This lives on, as you found out.
Support for using Homebrew packages was added.
It would be nice to allow Sage's build system to use MacPorts
in the same way it can use Homebrew. This is tracked at:
Contributions are welcome!
Update (2021-03-21)
There is recent progress on several fronts.
- A new SageMath macOS app, including OpenSSL, signed and notarized, is in beta testing.
- Building SageMath from source using installed MacPorts packages is becoming possible:
