More familiarity with computers may be required to build Sage from the source code. If you do have all the pre-requisite tools, the process should be completely painless, basically consisting in extracting the source tarball and typing make. It can take your computer a while to build Sage from the source code, although the procedure is fully automated and should need no human intervention. Building Sage from the source code has the major advantage that your install will be optimised for your particular computer and should therefore offer better performance and compatibility than a binary install. Moreover, it offers you full development capabilities: you can change absolutely any part of Sage or the programs on which it depends, and recompile the modified parts.
See http://wiki.sagemath.org/SupportedPlatforms for the full list of platforms on which Sage is supported and the level of support for these systems.
Sage is supported on a number of Linux, Mac OS X , Sun/Oracle Solaris and OpenSolaris releases, but not necessarily all versions of these operating systems. There is no native version of Sage which installs on Microsoft Windows, although Sage can be used on Windows with the aid of a virtual machine or the Cygwin Linux API layer.
Your computer comes with at least 4 GB of free disk space running one of the supported versions of an operating system listed at http://wiki.sagemath.org/SupportedPlatforms.
Sage also needs a C++ compiler and a Fortran compiler. The only configuration currently supported is matching versions of the C, C++ and Fortran compilers from the GNU Compiler Collection (GCC). Therefore, if you plan on using your own GCC compilers, then make sure that their versions match. Alternatively, Sage includes a GCC package, so that C, C++ and Fortran compilers will be built when the build system detects that it is needed, e.g., non-GCC compilers, or versions of the GCC compilers known to miscompile some components of Sage, or simply a missing C++ or Fortran compiler. Whatsoever, you always need at least a C compiler to build the GCC package and its prerequisites before the compilers it provides can be used. Note that you can always override this behavior through the environment variable SAGE_INSTALL_GCC, see Using alternative compilers and Environment variables.
Although some of Sage is written in Python, you do not need Python pre-installed on your computer, since the Sage installation includes virtually everything you need.
After extracting the Sage tarball, the subdirectory spkg contains the source distributions for everything on which Sage depends. We emphasize that all of this software is included with Sage, so you do not have to worry about trying to download and install any one of these packages (such as Python, for example) yourself.
When the Sage installation program is run, it will check that you have each of the above-listed prerequisites, and inform you of any that are missing, or have unsuitable versions.
On recent Debian or Ubuntu systems, the dpkg-dev package is needed for multiarch support.
On Cygwin, the lapack and liblapack-devel packages are required to provide ATLAS support as the ATLAS spkg is not built by default.
To check if you have the above prerequisites installed, for example perl, type:
command -v perl
on the command line. If it gives an error (or returns nothing), then either perl is not installed, or it is installed but not in your PATH.
On Linux systems (e.g., Ubuntu, Redhat, etc), ranlib is in the binutils package. The other programs are usually located in packages with their respective names. Assuming you have sufficient privileges, you can install the binutils and other necessary components. If you do not have the privileges to do this, ask your system administrator to do this, or build the components from source code. The method of installing additional software varies from distribution to distribution, but on a Debian based system (e.g. Ubuntu or Mint), you would use apt-get:
sudo apt-get install binutils gcc make m4 perl tar
On OS X systems, you need a recent version of Command Line Tools. It provides all the above requirements. You can download it for free at http://developer.apple.com/downloads/index.action?=command%20line%20tools provided you registered for a free Apple Developer account at http://developer.apple.com/register/. Alternatively, if you have already installed Xcode (which at the time of writing is freely available in the Mac App Store, or through http://developer.apple.com/downloads/ provided you registered for an Apple Developer account), you can open Xcode’s “Downloads” preference pane and install the command line tools from there. On pre-Lion OS X systems, the command line tools are not available as a separate download and you have to install the full-blown Xcode supporting your system version.
On Solaris, you would use pkgadd and on OpenSolaris ipf to install the necessary software.
On Cygwin, you would use the setup.exe program. As on Linux systems ranlib is provided by the binutils package. As far as compilers are concerned, you should either install matching versions of the gcc4-core, gcc4-g++, and gcc4-gfortran packages, or the gcc4-core package alone if you plan on using Sage’s own GCC.
On other systems, check the documentation for your particular operating system.
On OS X, the system-wide BSD tar supplied will build Sage, so there is no need to install the GNU tar.
On Solaris or OpenSolaris, the Sun/Oracle versions of make and tar are unsuitable for building Sage. Therefore, you must have the GNU versions of make and tar installed and they must be the first make and tar in your PATH.
On Solaris 10, a version of GNU make may be found at /usr/sfw/bin/gmake, but you will need to copy it somewhere else and rename it to make. The same is true for GNU tar; a version of GNU tar may be found at /usr/sfw/bin/gtar, but it will need to be copied somewhere else and renamed to tar. It is recommended to create a directory $HOME/bins-for-sage and to put the GNU versions of tar and make in that directory. Then ensure that $HOME/bins-for-sage is first in your PATH. That’s because Sage also needs /usr/ccs/bin in your PATH to execute programs like ar and ranlib, but /usr/ccs/bin has the Sun/Oracle versions of make and tar in it.
If you attempt to build Sage on AIX or HP-UX, you will need to install both GNU make and GNU tar.
Sage developers tend to use fairly recent versions of GCC. Nonetheless, Sage build process should succeed with any reasonable C compiler. This is because Sage will build GCC first (if needed) and then use that newly built GCC to compile Sage.
If you don’t want this and want to try building Sage with a different set of compilers, you need to set the environment variable SAGE_INSTALL_GCC to no.
If you are interested in working on support for commerical compilers from HP, IBM, Intel, Sun/Oracle, etc, or the open-source Clang, please email the sage-devel mailing list, also known as the sage-devel Google group at http://groups.google.com/group/sage-devel.
The following programs are recommended. They are not strictly required at build time or at run time, but provide additional capablities:
It is highly recommended that you have Latex installed, but it is not required.
On Linux systems, it is usually provided by packages derived from TeX Live and can be installed using:
sudo apt-get install texlive
or similar commands.
On other systems it might be necessary to install TeX Live from source code, which is quite easy, though a rather time-consuming process.
If you don’t have either ImageMagick or ffmpeg, you won’t be able to view animations. ffmpeg can produce animations in more different formats than ImageMagick, and seems to be faster than ImageMagick when creating animated GIFs. Either ImageMagick or dvipng is used for displaying some LaTeX output in the Sage notebook.
By default, the Sage notebook uses the HTTP protocol when you type the command notebook(). To run the notebook in secure mode by typing notebook(secure=True) which uses the HTTPS protocol, or to use OpenID authentication, you need to follow specific installation steps described in Building the notebook with SSL support.
Although all necessary components are provided through Sage optional packages, i.e. you can install a local version of OpenSSL by using Sage’s openssl spkg and running sage -i openssl as suggested in Building the notebook with SSL support (this requires an Internet connection), you might prefer to install OpenSSL and the OpenSSL development headers globally on your system.
On Linux systems, those are usually provided by the libssl and libssl-dev packages and can be installed using:
sudo apt-get install libssl libssl-dev
or similar commands.
On Linux systems, the OpenSSH server, client and utilities are usually provided by the openssh-server and openssh-client packages and can be installed using:
sudo apt-get install openssh-server openssh-client
or similar commands.
If you want to use Tcl/Tk libraries in Sage, you need to install the Tcl/Tk and its development headers before building Sage. Sage’s Python will then automatically recognize your system’s install of Tcl/Tk.
On Linux systems, these are usually provided by the tk and tk-dev (or tk-devel) packages which can be installed using:
sudo apt-get install tk tk-dev
or similar commands.
If you installed Sage first, all is not lost. You just need to rebuild Sage’s Python, , and ideally any part of Sage relying on it:
sage -f python # rebuild Python SAGE_UPGRADING=yes make # rebuild components of Sage depending on Python
after installing the Tcl/Tk development libraries as above.
sage: import _tkinter sage: import Tkinter
does not raise an ImportError, then it worked.
Installation from source is (potentially) very easy, because the distribution contains (essentially) everything on which Sage depends.
Make sure there are no spaces in the path name for the directory in which you build: several of Sage’s components will not build if there are spaces in the path. Running Sage from a directory with spaces in its name will also fail.
Go to http://www.sagemath.org/download-source.html, select a mirror, and download the file sage-x.y.z.tar.
This tarfile contains the source code for Sage and the source for all programs on which Sage depends. Note that this file is not compressed; it’s just a plain tarball (which happens to be full of compressed files).
Download it into any directory you have write access to, preferably on a fast filesystem, avoiding NFS and the like. On personal computers, any subdirectory of your HOME directory should do. The directory where you built Sage is NOT hardcoded. You should be able to safely move or rename that directory. (It’s a bug if this is not the case.)
Extract the tarfile:
tar xvf sage-x.y.z.tar
This creates a directory sage-x.y.z.
Change into that directory:
This is Sage’s home directory. It is also referred to as SAGE_ROOT or the top level Sage directory.
Optional, but highly recommended: Read the README.txt file there.
On OSX 10.4, OS 10.5, Solaris 10 and OpenSolaris, if you wish to build a 64-bit version of Sage, assuming your computer and operating system are 64-bit, type:
It should be noted that as of April 2011, 64-bit builds of Sage on both Solaris 10 and OpenSolaris are not very stable, so you are advised not to set SAGE64 to yes. This will then create stable 32-bit versions of Sage. See http://wiki.sagemath.org/solaris for the latest information.
Start the build process:
or if your system is multithreaded and you want to use several threads to build Sage:
MAKE='make -jNUM' make
to tell the make program to run NUM jobs in parallel when building Sage. This compiles Sage and all its dependencies.
Note that you do not need to be logged in as root, since no files are changed outside of the sage-x.y.z directory. In fact, it is inadvisable to build Sage as root, as the root account should only be used when absolutely necessary and mistyped commands can have serious consequences if you are logged in as root. There has been a bug reported (see trac ticket #9551) in Sage which would have overwritten a system file had the user been logged in as root.
Typing make performs the usual steps for each Sage’s dependency, but installs all the resulting files into the local build tree. Depending on the age and the architecture of your system, it can take from a few tens of minutes to several hours to build Sage from source. On really slow hardware, it can even take a few days to build Sage.
Each component of Sage has its own build log, saved in SAGE_ROOT/logs/pkgs. If the build of Sage fails, you will see a message mentioning which package(s) failed to build and the location of the log file for each failed package. If this happens, then paste the contents of these log file(s) to the Sage support newsgroup at http://groups.google.com/group/sage-support. If the log files are very large (and many are), then don’t paste the whole file, but make sure to include any error messages. It would also be helpful to include the type of operating system (Linux, OS X, Solaris, OpenSolaris, Cygwin, or any other system), the version and release date of that operating system and the version of the copy of Sage you are using. (There are no formal requirements for bug reports – just send them; we appreciate everything.)
See Make targets for some targets for the make command, Environment variables for additional informatio on useful environment variables used by Sage, and Building the notebook with SSL support for additional instruction on how to build the notebook with SSL support.
To start Sage, you can now simply type from Sage’s home directory:
You should see the Sage prompt, which will look something like this:
$ sage ---------------------------------------------------------------------- | Sage Version 5.8, Release Date: 2013-03-15 | | Type "notebook()" for the browser-based notebook interface. | | Type "help()" for help. | ---------------------------------------------------------------------- sage:
Note that Sage should take well under a minute when it starts for the first time, but can take several minutes if the file system is slow or busy. Since Sage opens a lot of files, it is preferable to install Sage on a fast filesystem if possible.
Just starting successfully tests that many of the components built correctly. Note that this should have been already automatically tested during the build process. If the above is not displayed (e.g., if you get a massive traceback), please report the problem, e.g., at http://groups.google.com/group/sage-support.
After Sage has started, try a simple command:
sage: 2 + 2 4
Or something slightly more complicated:
sage: factor(2005) 5 * 401
Optional, but highly recommended: Test the install by typing ./sage --testall. This runs most examples in the source code and makes sure that they run exactly as claimed. To test all examples, use ./sage --testall --optional=all --long; this will run examples that take a long time, and those that depend on optional packages and software, e.g., Mathematica or Magma. Some (optional) examples will therefore likely fail.
Alternatively, from within $SAGE_ROOT, you can type make test (respectively make ptest) to run all the standard test code serially (respectively in parallel).
Testing the Sage library can take from half an hour to several hours, depending on your hardware. On slow hardware building and testing Sage can even take several days!
Optional: Check the interfaces to any other software that you have available. Note that each interface calls its corresponding program by a particular name: Mathematica is invoked by calling math, Maple by calling maple, etc. The easiest way to change this name or perform other customizations is to create a redirection script in $SAGE_ROOT/local/bin. Sage inserts this directory at the front of your PATH, so your script may need to use an absolute path to avoid calling itself; also, your script should pass along all of its arguments. For example, a maple script might look like:
#!/bin/sh exec /etc/maple10.2/maple.tty "$@"
Optional: There are different possibilities to make using Sage a little easier:
Make a symbolic link from /usr/local/bin/sage (or another directory in your PATH) to $SAGE_ROOT/sage:
ln -s /path/to/sage-x.y.z/sage /usr/local/bin/sage
Now simply typing sage from any directory should be sufficient to run Sage.
Copy $SAGE_ROOT/sage to a location in your PATH. If you do this, make sure you edit the line:
at the beginning of the copied sage script according to the direction given there to something like:
(note that you have to change <SAGE_ROOT> above!). It is best to edit only the copy, not the original.
For KDE users, create a bash script called sage containing the lines (note that you have to change <SAGE_ROOT> below!):
#!/bin/bash konsole -T "sage" -e <SAGE_ROOT>/sage
make it executable:
chmod a+x sage
and put it somewhere in your PATH.
You can also make a KDE desktop icon with this line as the command (under the Application tab of the Properties of the icon, which you get my right clicking the mouse on the icon).
On Linux and OS X systems, you can make an alias to $SAGE_ROOT/sage. For example, put something similar to the following line in your .bashrc file:
(Note that you have to change <SAGE_ROOT> above!) Having done so, quit your terminal emulator and restart it. Now typing sage within your terminal emulator should start Sage.
Optional: Install optional Sage packages and databases. Type sage --optional to see a list of them (this requires an Internet connection), or visit http://www.sagemath.org/packages/optional/. Then type sage -i <package-name> to automatically download and install a given package.
Optional: Run the install_scripts command from within Sage to create GAP, GP, Maxima, Singular, etc., scripts in your PATH. Type install_scripts? in Sage for details.
Have fun! Discover some amazing conjectures!
Read this section if you are intending to run a Sage notebook server for multiple users.
For security, you may wish users to access the server using the HTTPS protocol (i.e., to run notebook(secure=True)). You also may want to use OpenID for user authentication. The first of these requires you to install pyOpenSSL, and they both require OpenSSL.
If you have OpenSSL and the OpenSSL development headers installed on your system, you can install pyOpenSSL by building Sage and then typing:
./sage -i pyopenssl
Alternatively, make ssl builds Sage and installs pyOpenSSL at once. Note that these commands require Internet access.
If you are missing either OpenSSL or OpenSSL’s development headers, you can install a local copy of both into your Sage installation first. Ideally, this should be done before installing Sage; otherwise, you should at least rebuild Sage’s Python, and ideally any part of Sage relying on it. The procedure is as follows (again, with a computer connected to the Internet). Starting from a fresh Sage tarball:
./sage -i openssl make ssl
And if you’ve already built Sage:
./sage -i openssl ./sage -f python SAGE_UPGRADING=yes make ssl
The third line will rebuild all parts of Sage that depend on Python; this can take a while.
Building on Cygwin will occasionally require “rebasing” dll files. Sage provides some scripts, located in $SAGE_LOCAL/bin, to do so:
Some systems may encounter this problem frequently enough to make building or testing difficult. If executing the above scripts or directly calling rebaseall does not solve rebasing issues, deleting the system-wide database and then regenerating it from scratch, e.g., by executing sage-rebaseall.sh, might help.
Finally, on Cygwin, one should also avoid the following:
To build Sage from scratch, you would typically execute make in Sage’s home directory to build Sage and its HTML documentation. The make command is pretty smart, so if your build of Sage is interrupted, then running make again should cause it to pick up where it left off. The make command can also be given options, which control what is built and how it is built:
Sage uses several environment variables to control its build process. Most users won’t need to set any of these: the build process just works on many platforms. (Note though that setting MAKE, as described below, can significantly speed up the process.) Building Sage involves building about 100 packages, each of which has its own compilation instructions.
Here are some of the more commonly used variables affecting the build process:
MAKE - one useful setting for this variable when building Sage is MAKE='make -jNUM' to tell the make program to run NUM jobs in parallel when building. Some people advise using more jobs than there are CPU cores, at least if the system is not heavily loaded and has plenty of RAM; for example, a good setting for NUM might be between 1 and 1.5 times the number of cores. In addition, the -l option sets a load limit: MAKE='make -j4 -l5.5, for example, tells make to try to use four jobs, but to not start more than one job if the system load average is above 5.5. See the manual page for GNU make: Command-line options and Parallel building.
Some users on single-core OS X machines have reported problems when building Sage with MAKE='make -jNUM' with NUM greater than one.
SAGE_NUM_THREADS - if set to a number, then when building the documentation, parallel doctesting, or running sage -b, use this many threads. If this is not set, then determine the number of threads using the value of the MAKE (see above) or MAKEFLAGS environment variables. If none of these specifies a number of jobs, use one thread (except for parallel testing: there we use a default of the number of CPU cores, with a maximum of 8 and a minimum of 2).
SAGE_PARALLEL_SPKG_BUILD - if set to no, then build spkgs serially rather than in parallel. If this is set to no, then each spkg may still take advantage of the setting of MAKE to build using multiple jobs, but the spkgs will be built one at a time. Alternatively, run make build-serial which sets this environment variable for you.
SAGE_CHECK - if set to yes, then during the build process, and when running sage -i <package-name> or sage -f <package-name>, run the test suite for each package which has one. See also SAGE_CHECK_PACKAGES.
SAGE_CHECK_PACKAGES - if SAGE_CHECK is set to yes, then the default behavior is to run test suites for all spkgs which contain them. If SAGE_CHECK_PACKAGES is set, it should be a comma-separated list of strings of the form package-name or !package-name. An entry package-name means to run the test suite for the named package regardless of the setting of SAGE_CHECK. An entry !package-name means to skip its test suite. So if this is set to mpir,!python, then always run the test suite for MPIR, but always skip the test suite for Python.
As of this writing (April 2013, Sage 5.8), the test suite for the Python spkg fails on most platforms. So when this variable is empty or unset, Sage uses a default of !python.
SAGE64 - if set to yes, then build a 64-bit binary on platforms which default to 32-bit, even though they can build 64-bit binaries. It adds the compiler flag -m64 when compiling programs. The SAGE64 variable is mainly of use on OS X (pre 10.6), Solaris and OpenSolaris, though it will add the -m64 flag on any operating system. If you are running Linux or version 10.6 or later of OS X on a 64-bit machine, then Sage will automatically build a 64-bit binary, so this variable does not need to be set.
CFLAG64 - default value -m64. If Sage detects that it should build a 64-bit binary, then it uses this flag when compiling C code. Modify it if necessary for your system and C compiler. This should not be necessary on most systems – this flag will typically be set automatically, based on the setting of SAGE64, for example.
SAGE_INSTALL_GCC - by default, Sage will automatically detect whether to install the GNU Compiler Collection (GCC) package or not (depending on whether C, C++ and Fortran compilers are present and the versions of those compilers). Setting SAGE_INSTALL_GCC=yes will force Sage to install GCC. Setting SAGE_INSTALL_GCC=no will prevent Sage from installing GCC.
SAGE_INSTALL_CCACHE - by default Sage doesn’t install ccache, however by setting SAGE_INSTALL_CCACHE=yes Sage will install ccache. Because the Sage distribution is quite large, the maximum cache is set to 4G. This can be changed by running sage -sh -c "ccache --max-size=SIZE", where SIZE is specified in gigabytes, megabytes, or kilobytes by appending a “G”, “M”, or “K”.
Sage does not include the sources for ccache since it is an optional package. Because of this, it is necessary to have an Internet connection while building ccache for Sage, so that Sage can pull down the necessary sources.
SAGE_DEBUG - controls debugging support. There are three different possible values:
SAGE_SPKG_LIST_FILES - if set to yes, then enable verbose extraction of tar files, i.e. Sage’s spkg files. Since some spkgs contain such a huge number of files that the log files get very large and harder to search (and listing the contained files is usually less valuable), we decided to turn this off by default. This variable affects builds of Sage with make (and sage --upgrade) as well as the manual installation of individual spkgs with e.g. sage -i or sage -f.
SAGE_SPKG_INSTALL_DOCS - if set to yes, then install package-specific documentation to $SAGE_ROOT/local/share/doc/PACKAGE_NAME/ when an spkg is installed. This option may not be supported by all spkgs. Some spkgs might also assume that certain programs are available on the system (for example, latex or pdflatex).
SAGE_DOC_MATHJAX - by default, any LaTeX code in Sage’s documentation is processed by MathJax. If this variable is set to no, then MathJax is not used – instead, math is processed using LaTeX and converted by dvipng to image files, and then those files are included into the documentation. Typically, building the documentation using LaTeX and dvipng takes longer and uses more memory and disk space than using MathJax.
SAGE_BUILD_DIR - the default behavior is to build each spkg in a subdirectory of $SAGE_ROOT/spkg/build/; for example, build atlas-3.8.3.p12.spkg in the directory $SAGE_ROOT/spkg/build/atlas-3.8.3.p12/. If this variable is set, then build in $SAGE_BUILD_DIR/atlas-3.8.3.p12/ instead. If the directory $SAGE_BUILD_DIR does not exist, it is created. As of this writing (Sage 4.8), when building the standard Sage packages, 1.5 gigabytes of free space are required in this directory (or more if SAGE_KEEP_BUILT_SPKGS=yes – see below); the exact amount of required space varies from platform to platform. For example, the block size of the file system will affect the amount of space used, since some spkgs contain many small files.
The variable SAGE_BUILD_DIR must be set to the full path name of either an existing directory for which the user has write permissions, or to the full path name of a nonexistent directory which the user has permission to create. The path name must contain no spaces.
SAGE_KEEP_BUILT_SPKGS - the default behavior is to delete each build directory – the appropriate subdirectory of $SAGE_ROOT/spkg/build or $SAGE_BUILD_DIR – after each spkg is successfully built, and to keep it if there were errors installing the spkg. Set this variable to yes to keep the subdirectory regardless. Furthermore, if you install an spkg for which there is already a corresponding subdirectory, for example left over from a previous build, then the default behavior is to delete that old subdirectory. If this variable is set to yes, then the old subdirectory is moved to $SAGE_ROOT/spkg/build/old/ (or $SAGE_BUILD_DIR/old), overwriting any already existing file or directory with the same name.
After a full build of Sage (as of version 4.8), these subdirectories can take up to 6 gigabytes of storage, in total, depending on the platform and the block size of the file system. If you always set this variable to yes, it can take even more space: rebuilding every spkg would use double the amount of space, and any upgrades to spkgs would create still more directories, using still more space.
In an existing Sage installation, running sage -i -s <package-name> or sage -f -s <package-name> installs the spkg <package-name> and keeps the corresponding build directory; thus setting SAGE_KEEP_BUILT_SPKGS to yes mimics this behavior when building Sage from scratch or when installing individual spkgs. So you can set this variable to yes instead of using the -s flag for sage -i and sage -f.
SAGE_FAT_BINARY - to prepare a binary distribution that will run on the widest range of target machines, set this variable to yes before building Sage:
export SAGE_FAT_BINARY="yes" make ./sage --bdist x.y.z-fat
Variables to set if you’re trying to build Sage with an unusual setup, e.g., an unsupported machine or an unusual compiler:
SAGE_PORT - if you try to build Sage on a platform which is recognized as being unsupported (e.g. AIX, or HP-UX), or with a compiler which is unsupported (anything except GCC), you will see a message saying something like:
You are attempting to build Sage on IBM's AIX operating system, which is not a supported platform for Sage yet. Things may or may not work. If you would like to help port Sage to AIX, please join the sage-devel discussion list -- see http://groups.google.com/group/sage-devel The Sage community would also appreciate any patches you submit. To get past this message and try building Sage anyway, export the variable SAGE_PORT to something non-empty.
If this is case and you want to try to build Sage anyway, follow the directions: set SAGE_PORT to something non-empty (and expect to run into problems).
SAGE_USE_OLD_GCC - the Sage build process requires GCC with a version number of at least 4.0.1. If the most recent version of GCC on your system is the older 3.4.x series and you want to build with SAGE_INSTALL_GCC=no, then set SAGE_USE_OLD_GCC to something non-empty. Expect the build to fail in this case.
Environment variables dealing with specific Sage packages:
SAGE_ATLAS_ARCH - if you are compiling ATLAS (in particular, if SAGE_ATLAS_LIB is not set), you can use this environment variable to set a particular architecture and instruction set extension. The syntax is SAGE_ATLAS_ARCH=arch[,isaext1][,isaext2]...[,isaextN]. While ATLAS comes with precomputed timings for a variety of CPUs, it only uses them if it finds an exact match. Otherwise, ATLAS runs through a lengthy automated tuning process in order to optimize performance for your particular system, which can take several days on slow and unusual systems. You drastically reduce the total Sage compile time if you manually select a suitable architecture. It is recommended to specify a suitable architecture on laptops or other systems with CPU throttling or if you want to distribute the binaries. Available architectures are
POWER3, POWER4, POWER5, PPCG4, PPCG5, P5, P5MMX, PPRO, PII, PIII, PM, CoreSolo, CoreDuo, Core2Solo, Core2, Corei7, P4, P4E, Efficeon, K7, HAMMER, AMD64K10h, IA64Itan, IA64Itan2, USI, USII, USIII, USIV, UnknownUS, MIPSR1xK, MIPSICE9
and instruction set extensions are
AltiVec, SSE3, SSE2, SSE1, 3DNow.
In addition, you can also set
would be appropriate for a Core i7 CPU.
SAGE_ATLAS_LIB - if you have an installation of ATLAS on your system and you want Sage to use it instead of building and installing its own version of ATLAS, set this variable to be the directory containing your ATLAS installation. It should contain the files libatlas, liblapack, libcblas, and libf77blas with extensions .a, .so, or .dylib. For backward compatibility, the libraries may also be in the subdirectory SAGE_ATLAS_LIB/lib/.
SAGE_MATPLOTLIB_GUI - if set to anything non-empty except no, then Sage will attempt to build the graphical backend when it builds the matplotlib package.
INCLUDE_MPFR_PATCH - this is used to add a patch to MPFR to bypass a bug in the memset function affecting sun4v machines with versions of Solaris earlier than Solaris 10 update 8 (10/09). Earlier versions of Solaris 10 can be patched by applying Sun patch 142542-01. Recognized values are:
SAGE_BINARY_BUILD - used by the pil package. If set to yes, then force Sage to use the versions of libjpeg, libtiff and libpng from $SAGE_ROOT/local/lib. Otherwise, allow the use of the system’s versions of these libraries.
SAGE_PIL_NOTK - used by the pil package. If set to yes, then disable building TK. If this is not set, then this should be dealt with automatically: Sage tries to build the pil package with TK support enabled, but if it runs into problems, it tries building again with TK disabled. So only use this variable to force TK to be disabled. (Building the pil package is pretty fast – less than a minute on many systems – so allowing it to build twice is not a serious issue.)
Some standard environment variables which are used by Sage:
The following Fortran-related environment variables are deprecated since Sage 5.3 and support for these will likely be removed. They are still recognized, but should not be used for new setups.
Sage uses the following environment variables when it runs:
DOT_SAGE - this is the directory, to which the user has read and write access, where Sage stores a number of files. The default location is $HOME/.sage/.
SAGE_STARTUP_FILE - a file including commands to be executed every time Sage starts. The default value is $DOT_SAGE/init.sage.
SAGE_SERVER - if you want to install a Sage package using sage -i <package-name>, Sage downloads the file from the web, using the address http://www.sagemath.org/ by default, or the address given by SAGE_SERVER if it is set. If you wish to set up your own server, then note that Sage will search the directories:
for packages. See the script $SAGE_ROOT/spkg/bin/sage-spkg for the implementation.
SAGE_PATH - a colon-separated list of directories which Sage searches when trying to locate Python libraries.
SAGE_BROWSER - on most platforms, Sage will detect the command to run a web browser, but if this doesn’t seem to work on your machine, set this variable to the appropriate command.
SAGE_ORIG_LD_LIBRARY_PATH_SET - set this to something non-empty to force Sage to set the LD_LIBRARY_PATH variable before executing system commands.
SAGE_ORIG_DYLD_LIBRARY_PATH_SET - similar, but only used on OS X to set the DYLD_LIBRARY_PATH variable.
SAGE_CBLAS - used in the file SAGE_ROOT/devel/sage/sage/misc/cython.py. Set this to the base name of the BLAS library file on your system if you want to override the default setting. That is, if the relevant file is called libcblas_new.so or libcblas_new.dylib, then set this to cblas_new.
Sage overrides the user’s settings of the following variables:
Variables dealing with doctesting:
This section addresses the question of how a system administrator can install a single copy of Sage in a multi-user computer network.
After building Sage, you may optionally copy or move the entire build tree to /usr/local or another location. If you do this, then you must run ./sage once so that various hardcoded locations get updated. For this reason, it might be easier to simply build Sage in its final location.
Make a symbolic link to the sage script in /usr/local/bin:
ln -s /path/to/sage-x.y.z/sage /usr/local/bin/sage
Alternatively, copy the Sage script:
cp /path/to/sage-x.y.z/sage /usr/local/bin/sage
If you do this, make sure you edit the line:
at the beginning of the copied sage script according to the direction given there to something like:
(note that you have to change <SAGE_ROOT> above!). It is recommended not to edit the original sage script, only the copy at /usr/local/bin/sage.
Make sure that all files in the Sage tree are readable by all (note that you have to change <SAGE_ROOT> below!):
chmod a+rX -R <SAGE_ROOT>
Optionally, you can test Sage by running:
or make ptestlong which tests files in parallel using multiple processes. You can also omit long to skip tests which take a long time.
Sometimes the ATLAS spkg can fail to build. Some things to check for:
It has been reported (see trac ticket #13947) that the zn_poly spkg fails to build on loaded systems, especially on Mac OS X and Cygwin. If you encounter this problem, you can try to build zn_poly serially before reissuing make:
MAKE="make -j1" ./sage -i zn_poly && make
This page was last updated in April 2013 (Sage 5.9).