Revision history [back]
 | 1 | initial version |
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, 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
| | 2 | No.2 Revision |
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
sure an SSL-enabled SSL-enabled
Python will be built.
make -s V=0 openssl
Then build the rest of Sage:
make -s V=0
| | 3 | No.3 Revision |
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!
| | 4 | No.4 Revision |
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)
Sage Trac ticket 30504 was merged, adding MacPorts package information.
Sage Trac ticket 31505 allows building Sage using MacPorts packages. It needs review.
| | 5 | No.5 Revision |
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:
- Sage Trac ticket 30504
- Sage Trac ticket 31505
- Sage Trac ticket 30504
