Scientific Core Library Stack

SCLS exists for the practical problem of getting scientific libraries to build, install, and work together on real machines. It targets environments where the system packages are too old, incomplete, inconsistent across dependencies, or simply unavailable for the platform in front of you.

SCLS is intended for scientists, research software engineers, and HPC maintainers who need PETSc, Ipopt, HDF5, NetCDF, OpenMPI, sparse solvers, and math libraries to agree on compiler and ABI choices, MPI, BLAS/LAPACK, rpaths, and install layout.

The stack covers the core numerical infrastructure used by downstream scientific software: BLAS/LAPACK, MPI-enabled math libraries, sparse direct solvers (MUMPS, SuperLU, STRUMPACK, SPRAL), nonlinear optimization (Ipopt), graph partitioners, I/O libraries, and the dependencies needed to make them coexist. SCLS is not three separate build systems: RPM packages, DEB packages, and direct Unix installs are generated from the same package recipes and flavor definitions, which keeps Linux and macOS behavior aligned.

SCLS ships as OS-level packages where possible rather than as Docker images or Spack environments. Docker is useful when an application brings its whole runtime with it, but containers can complicate MPI launches and shift stack management from the OS package manager to a container runtime. Spack is well suited to per-user, bespoke concretizations of a large software graph; SCLS instead favors a stable shared stack. RPMs and DEBs fit existing sysadmin workflows, provide normal install and uninstall semantics, and let users and projects share one managed binary installation in a predictable prefix.

On macOS, SCLS does not use Homebrew as the stack manager for the same reason. Homebrew puts user tools and scientific libraries in one shared prefix (/usr/local on Intel Macs and /opt/homebrew on Apple Silicon), which makes a controlled, version-pinned scientific stack awkward. Keeping the macOS stack in the SCLS-owned /opt/scls prefix gives it the same isolation and activation model as the Linux binaries, so downstream code and environment variables behave consistently across platforms.

The intended result is not maximum configurability. It is a coherent, reproducible stack that downstream codes can link against without constant manual repair.

SCLS is deliberately opinionated. It is a curated build and packaging system, not a general-purpose meta-build framework. It makes a small number of project-wide choices so the resulting libraries share the same compiler assumptions, math backend, integer model, MPI implementation, and installation layout:

• GCC is the default toolchain because it is widely available, reliable, and has strong Fortran support.
• The math backend is selected by flavor (OpenBLAS for gcc, Intel MKL for mkl, reference BLAS/LAPACK for debug), not toggled package by package.
• OpenMPI is the default MPI implementation.
• Shared libraries are the normal target.
• LP64 (32-bit BLAS/LAPACK integer indices) is the default; ILP64 can be enabled in the build scripts.
• Numerical correctness matters more than aggressive flag games — no -ffast-math.
• Binaries are built from explicit recipe dependencies, not from whatever optional libraries the build host happens to expose through autodetection.

The stack also deliberately leaves some things out:

• No Python in the stack. Interpreter choice (system, pyenv, conda, Spack, modules) is site- and user-specific, so recipes disable Python and other language bindings by default. Users bring their own interpreter and link it to the installed C/C++ libraries.
• No Boost. Modern C++ (C++17/20) covers most of what scientific code once used Boost for, and the libraries SCLS targets either never required it or have dropped the dependency.
• No GPL in the published binaries. Every package in the public binary flavors carries a BSD-3-Clause-compatible license: permissive, or weak copyleft (LGPL, CeCILL-C, EPL-2.0) whose obligations attach to the library itself rather than to code that merely links against it. GPL libraries of any version are excluded, so downstream codes can link SCLS without strong-copyleft concerns. GPL build tools are allowed in the build scripts, because macOS and other Unix systems without SCLS binaries may need them; they run during the build and are not linked into the delivered libraries. The GCC runtime libraries are linked under the GCC Runtime Library Exception. See the license policy for details.

This bias toward curation is intentional. If a project needs many custom feature toggles for a single package, SCLS is probably the wrong tool. If it needs PETSc, Ipopt, HDF5, OpenBLAS, NetCDF, MUMPS, and related libraries to build and coexist predictably, SCLS is built for that job.

A flavor is the unit of consistency in SCLS. It defines the target platform, compiler family, optimization flags, math backend, MPI choice, integer model, and install prefix for the entire stack. Public Linux binary flavors install into distinct /opt/scls/<flavor> prefixes; source-built flavors declare their own prefix.

• scls-gcc — GCC + OpenBLAS. Default production stack with GCC, OpenBLAS, OpenMPI, LP64 integers, and x86-64-v3 optimization flags.
• scls-mkl — GCC + Intel MKL. Production stack for sites that use Intel oneAPI MKL for BLAS, LAPACK, and ScaLAPACK while compiling the rest with GCC.
• scls-debug — GCC + Reference BLAS/LAPACK. Diagnostic stack compiled with -Og -g and linked against Netlib reference BLAS/LAPACK for Valgrind, sanitizers, and debuggers.

The public binary repositories currently target Enterprise Linux 9 and 10, Amazon Linux 2023, Ubuntu 24.04 LTS, and Ubuntu 26.04 LTS. The SCLS source tree can also build local RPMs on other RHEL-family systems, local DEBs on Debian-family systems, and direct Unix installs on macOS and other Unix systems.

Additional source-build flavors include lbl for an LBL-specific prefix, intel for Intel compiler builds, gcc-mkl-cuda for CUDA-enabled experiments, and macos. See the flavors/ directory for the complete list.

CUDA binaries are not distributed, because a CUDA-linked stack would tie users to a specific driver and toolkit version. Users who need GPU acceleration can use the gcc-mkl-cuda source-build flavor and link against a locally installed CUDA toolkit.

On macOS, the stack uses OpenBLAS rather than Apple's Accelerate framework. The macos flavor builds its own GCC for Fortran support. Pairing GCC-built Fortran with Accelerate is fragile: Accelerate is tuned for Apple's Clang toolchain, and its ABI is awkward to use from GCC. OpenBLAS works reliably with GCC, keeps math behavior aligned with the Linux binary flavors, and favors compute throughput over the performance and power tradeoffs that shape Accelerate.

The Unix build script also includes GPL build tools and selected LGPL-3 arbitrary-precision dependencies that are excluded from the public Linux binary flavors. See the build-tools table below.

First, install the release package for your distribution (choose one):

Enterprise Linux 9:

sudo dnf install https://belfem.lbl.gov/scls/el9/x86_64/Packages/scls-release-2026-1.el9.noarch.rpm

Enterprise Linux 10:

sudo dnf install https://belfem.lbl.gov/scls/el10/x86_64/Packages/scls-release-2026-1.el10.noarch.rpm

Amazon Linux 2023:

sudo dnf install https://belfem.lbl.gov/scls/amzn2023/x86_64/Packages/scls-release-2026-1.amzn2023.noarch.rpm

Then install a flavor:

sudo dnf install scls-<flavor>

RPM builds also provide an optional examples meta-package. Install scls-<flavor>-examples if you want the upstream PETSc, SLEPc, and SUNDIALS example sources on disk.

After installation, activate the environment:

source /opt/scls/<flavor>/share/scls/activate

This adds the stack's bin/ directory to PATH, exposes package metadata through PKG_CONFIG_PATH and CMAKE_PREFIX_PATH, and sets SCLS and SCLS_FLAVOR. Runtime library lookup uses rpaths, not LD_LIBRARY_PATH. Once the environment is active, run scls help to list the runtime subcommands: scls flavor, scls list, scls info <package>, scls env, scls prefix, scls license, and scls deactivate.

SCLS publishes one APT repository per Ubuntu LTS release, each with its own package pool. Pick the line that matches your release (lsb_release -cs prints the codename):

Unlike dnf, apt does not install packages directly from a URL. Download and install the keyring and repository-configuration package for your release first. On Ubuntu 26.04:

wget https://belfem.lbl.gov/scls/ubuntu/resolute/pool/main/s/scls-archive-keyring/scls-archive-keyring_2026-1_all.deb
sudo apt install ./scls-archive-keyring_2026-1_all.deb

On Ubuntu 24.04:

wget https://belfem.lbl.gov/scls/ubuntu/noble/pool/main/s/scls-archive-keyring/scls-archive-keyring_2026-2_all.deb
sudo apt install ./scls-archive-keyring_2026-2_all.deb

This installs the SCLS public key at /etc/apt/keyrings/scls-archive-keyring.gpg and a deb822-format scls.sources file at /etc/apt/sources.list.d/. If you prefer to configure the repository by hand, install the key at that path and write the equivalent /etc/apt/sources.list.d/scls.sources yourself, for example on Ubuntu 26.04:

Types: deb
URIs: https://belfem.lbl.gov/scls/ubuntu/resolute
Suites: resolute
Components: main
Signed-By: /etc/apt/keyrings/scls-archive-keyring.gpg

Then refresh apt and install a flavor:

sudo apt update
sudo apt install scls-<flavor>

The original Ubuntu 24.04 repository URL, https://belfem.lbl.gov/scls/ubuntu with suite noble, still works, so existing 24.04 installations need no change.

New in this release: Ubuntu 26.04 LTS is now a supported target. The Ubuntu 24.04 packages were relinked so that every library records its direct dependencies the same way as the Enterprise Linux builds; package versions did not change, so an existing 24.04 installation picks up the relinked files by reinstalling its SCLS packages:

sudo apt update
sudo apt install --reinstall $(dpkg-query -W -f='${Package}\n' 'scls-*')

DEB builds produce per-package example subpackages when recipes define them, such as scls-<flavor>-petsc-examples. Unlike the RPM distribution, they do not currently provide an all-examples meta-package.

After installation, activate the environment the same way as on Enterprise Linux:

source /opt/scls/<flavor>/share/scls/activate

The runtime scls command, the per-flavor prefix layout, and the activation script are identical between the RPM and DEB binary distributions.

Outside the public Enterprise Linux and Ubuntu repositories, clone the SCLS source tree and use the ./scls wrapper. It selects RPM mode on supported RHEL-family hosts, including Amazon Linux 2023; DEB mode on Debian-family systems; and direct Unix-install mode elsewhere.

On Debian-family systems outside the public Ubuntu 24.04 and 26.04 repositories, ./scls can still build local .deb packages. On macOS and other Unix systems, the Unix builder installs the packages directly into the selected SCLS prefix.

macOS is supported on both Intel Macs and Apple Silicon; Apple Silicon support is no longer beta, and the stack has been built from source on both. Upstream GCC carries no aarch64-apple-darwin target of its own, so on arm64 hosts SCLS vendors the Apple Silicon GCC patch maintained by Homebrew and applies it automatically. Rosetta is not a supported path: an x86_64 shell gets the Intel toolchain instead.

The macOS flavor assumes familiarity with a Unix toolchain: installing Xcode Command Line Tools, understanding linker and sysroot settings, and interpreting build logs that point to an SDK or path issue. It builds its own GCC for Fortran support, which adds time to the first build. If that bootstrap (Apple Clang building GCC 16) fails, Homebrew's prebuilt GCC is supported as a fallback on either architecture. See the macOS build guide for prerequisites, the step-by-step flow, and the two Homebrew fallback routes.

Quick start:

1. Clone the repository:
   

   git clone https://github.com/cmesse/scls.git
   cd scls

2. Create flavor.conf for your platform. Linux (the default flavor, also used for local package builds):
   

   echo "flavor: gcc" > flavor.conf

   macOS:

   echo "flavor: macos" > flavor.conf

3. Build and install the full flavor in dependency order:
   

   ./scls build all

   For a granular or resumable flow, build and install the next package:

   ./scls build next
   ./scls install next

   Or build a specific package:

   ./scls build petsc
   ./scls install petsc

4. Activate the environment. Linux / local package flavors:
   

   source /opt/scls/<flavor>/share/scls/activate

   macOS:

   source /opt/scls/share/scls/activate

   Use <prefix>/share/scls/activate for any source-built flavor with a custom prefix.

The wrapper also supports ./scls build, ./scls install, ./scls spec (RPM mode), ./scls list, ./scls order, and ./scls check-updates. Run ./scls with no arguments to see the usage summary.

Once the environment is active, the stack is visible to ordinary build tools. A minimal PETSc example:

source /opt/scls/gcc/share/scls/activate
mpicc myapp.c -o myapp $(pkg-config --cflags --libs petsc)
mpirun -n 4 ./myapp

CMake projects can use the activated prefix directly:

cmake -S . -B build -DCMAKE_PREFIX_PATH="$SCLS"
cmake --build build

The activation script sets PATH, PKG_CONFIG_PATH, and CMAKE_PREFIX_PATH. It exports SCLS and SCLS_FLAVOR, plus PETSC_DIR, SLEPC_DIR, and MPI_HOME when those packages are installed. For PETSc, PETSC_DIR points to the installed SCLS prefix and PETSC_ARCH is intentionally empty: SCLS installs PETSc as a prefix-installed library, not an in-place source tree. pkg-config, CMake's find_package, and package-specific configuration scripts therefore work without further setup.

LD_LIBRARY_PATH is deliberately not modified. Every shared library in the stack has an rpath to its install prefix, so binaries find their dependencies at runtime without changing the loader search path for every child process. The activation script does remove stale SCLS entries from a previously active flavor, so switching stacks is a clean reactivation rather than an accumulating set of path entries.

To build your own flavor, contribute recipes, or file issues:

https://github.com/cmesse/scls

The table below lists packages that ship in the distributed binary flavors. Their licenses are BSD-3-Clause-compatible: permissive, or weak copyleft (LGPL, CeCILL-C, EPL-2.0). No GPL package, of any version, is part of the public binary flavors.

Using IPOPT and HSL

The SCLS build of Ipopt uses the stack's linear solvers: the MPI build of MUMPS (the default linear_solver) and SPRAL's SSIDS on every flavor, plus MKL Pardiso on the MKL flavors. Users choose a solver in ipopt.opt; SSIDS also requires OMP_CANCELLATION=TRUE in the environment of the program that uses it. The HSL solvers (MA27, MA57, HSL_MA77, HSL_MA86, HSL_MA97) are proprietary, so SCLS ships neither their source nor a binary. SCLS provides build scripts: ./scls build hsl and ./scls install hsl turn your own Coin-HSL source tarball into a private library linked against the stack's METIS and BLAS/LAPACK. The packaged Ipopt loads that library at runtime. You must provide your own sources and HSL license, obtained from STFC; see HSL_BUILD.md for details.

The packages below are not part of the public Linux binary flavors. The build scripts provide them for source builds, especially macos and Unix systems without SCLS binaries, where the system does not supply them. The GNU build tools (autoconf, automake, libtool, m4, make, sed, bison, texinfo, and pkg-config) are GPL-licensed; they are executed during the build and are not linked into the scientific libraries. SCLS also includes a GCC recipe, so the macos flavor can build its own Fortran-capable compiler from source; the GCC runtime libraries are linked under the GCC Runtime Library Exception. GMP and MPFR are LGPL libraries that GCC and parts of the stack need; the public Linux flavors use the distribution's packages for them instead of shipping SCLS builds.

SCLS itself is licensed under the Lawrence Berkeley National Laboratory BSD variant (BSD-3-Clause-LBNL). Individual packages retain their own licenses as shown in the table above.

This software is provided "AS IS" without warranty of any kind.