Scientific Core Library Stack 2026

SCLS packages a coherent stack of scientific libraries — BLAS/LAPACK, MPI, sparse solvers, PETSc, HDF5, and their dependencies — as RPMs for Enterprise Linux, as DEBs for Ubuntu 24.04 LTS, and as source-built installs for macOS and other Unix systems. After enabling a public binary repository, one package-manager command installs a complete, mutually compatible flavor.

Public Linux binary flavors install under /opt/scls/<flavor>, so several stacks can coexist on the same host without interfering with the operating system. Source-built site flavors may choose their own prefix, and the macOS flavor installs directly under /opt/scls.

Send comments, questions, or suggestions to Christian Messe: [javascript protected email]

Purpose

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, HDF5, NetCDF, OpenMPI, sparse solvers, and math libraries to agree on compilers, ABI, 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 solvers, 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 a good fit when an application brings its entire runtime with it, but containers add isolation that scientific and HPC workloads usually do not want — they complicate MPI launches and move responsibility for the stack from the OS package manager to a runtime. Spack excels when every user wants their own bespoke concretization of a large software graph, but it optimizes for combinatorial flexibility rather than a stable, shared stack. RPMs and DEBs map cleanly onto existing sysadmin workflows, give normal install/uninstall semantics, and let multiple users and projects share a single managed binary installation in a predictable prefix.

On macOS, SCLS does not piggyback on Homebrew for similar reasons. Homebrew installs everything into a single shared prefix (/usr/local on Intel Macs, /opt/homebrew on Apple Silicon) where user-level tools and scientific libraries share the same namespace, making version pinning and controlled scientific stacks 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, activation, 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.

Design Philosophy

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 for its open availability, reliability, and 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 turned on optionally 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 against the installed C/C++ libraries.
• No Boost. Modern C++ (C++17/20) covers most of what scientific code used to need from Boost, and the libraries SCLS cares about either never required it or have dropped the dependency.
• No GPL-3 linkable libraries in binary flavors, so downstream codes can link SCLS without copyleft concerns. GPL-3 build tools are fine because they run during the build and are not linked into the delivered libraries; GPL-2, LGPL, and CeCILL-C scientific libraries are allowed when their source and redistribution obligations are practical to satisfy. 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, HDF5, OpenBLAS, NetCDF, MUMPS, and related libraries to build and coexist predictably, SCLS is built for that job.

Flavors

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, and Ubuntu 24.04 LTS. The same repository can also build local RPMs on other RHEL-family systems, local DEBs on Debian-family systems, or direct Unix installs on macOS and non-RPM/non-DEB Unix systems.

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

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 (SCLS ships a GCC build script for exactly this purpose), and pairing GCC-built Fortran with Accelerate is fragile — Accelerate is tuned for Apple's Clang toolchain and its ABI story is awkward from the GCC side. OpenBLAS is well-understood with GCC, keeps the math behavior identical to the Linux binary flavors, and is tuned for compute throughput rather than the performance/power tradeoffs that shape Accelerate.

The Unix build script also provides GPL-3 build tools and selected LGPL-3 arbitrary-precision dependencies that are left out of the public Linux binary flavors. See the second package table below.

Installation on Enterprise Linux 9 / 10 and Amazon Linux 2023

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 / SCLS_FLAVOR. Runtime library lookup is handled by rpaths, not by modifying LD_LIBRARY_PATH. Run scls help once the environment is active for the list of runtime subcommands (scls flavor, scls list, scls info <package>, scls env, scls prefix, scls license, scls deactivate).

Installation on Ubuntu 24.04 LTS

Ubuntu 24.04 LTS (Noble Numbat) is the supported Debian-family target. Unlike dnf, apt does not install packages directly from a URL, so the keyring + repository-configuration package is fetched first and then installed from the local file:

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

This drops the SCLS public key under /etc/apt/keyrings/scls-archive-keyring.gpg and a deb822-format scls.sources file under /etc/apt/sources.list.d/. Then refresh apt and install a flavor:

sudo apt update
sudo apt install scls-<flavor>

DEB builds produce per-package example subpackages when recipes define them, such as scls-<flavor>-petsc-examples; unlike the RPM path, there is not currently 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.

Building from Source and Local Packages

On platforms outside the public Enterprise Linux and Ubuntu repositories, clone the repository and use the ./scls wrapper. The wrapper 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 repository, ./scls can still build local .deb packages. On macOS and non-RPM/non-DEB Unix systems, the same recipes are installed directly into the selected SCLS prefix through the Unix builder.

macOS support is currently beta, developed and tested on Intel Macs; Apple Silicon is planned but unverified. The flavor assumes you are comfortable with a Unix toolchain — installing Xcode Command Line Tools, understanding how linker and sysroot settings work, and knowing what to do when a build log points at an SDK or path issue. The macos flavor also builds its own GCC for Fortran support, which adds time to the first build. If the built-in GCC bootstrap (Apple Clang building GCC 15) fails, Homebrew's prebuilt GCC is supported as a fallback. 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 default / local package build:
   

   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 build wrapper itself supports ./scls build all, ./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.

Using the Stack

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, and exports SCLS and SCLS_FLAVOR plus PETSC_DIR, SLEPC_DIR, and MPI_HOME when those packages are installed. For PETSc, PETSC_DIR points at the installed SCLS prefix and PETSC_ARCH is intentionally empty because SCLS installs PETSc as a prefix-installed library, not as an in-place PETSc 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 is built with an rpath into its install prefix, so binaries find their dependencies at runtime without the activation script having to poison the loader search path of every child process. The activation script does, however, clean any stale SCLS entries left behind by a previously-activated flavor — switching stacks is a clean re-activation rather than an accumulating stack of path entries.

Git Repository

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

https://github.com/cmesse/scls

Packages

The table below lists packages that ship in the distributed binary flavors. Their licenses are permissive, weak-copyleft, or otherwise accepted under the SCLS binary-distribution policy. GPL-3 linkable libraries are excluded from the public binary flavors.

Source-Only Packages (GPL-3 / LGPL-3)

The packages below carry GPL-3 or LGPL-3-family licenses and are therefore not included in the public Linux binary flavors. They are targeted primarily at source builds, especially macos, where Xcode and the Command Line Tools do not ship the GNU build-tool chain (autoconf, automake, libtool, m4, bison, texinfo) or the multiprecision dependencies the scientific stack needs. SCLS also ships a recipe for GCC itself, so the macos flavor can produce its own Fortran-capable toolchain from source. Some dependencies, such as GMP, MPFR, and MPC for GCC, may be consumed as GCC extra sources rather than shipped as public Linux binary packages.

License

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.