ampl/gsl: the GNU Scientific Library with a CMake build and AMPL bindings

A mirror of GSL with two additions, not a fork

The README is explicit about what this repository is. It contains a copy of the latest stable version of GSL, the GNU Scientific Library, which is a collection of numerical routines for scientific computing, with two main additions: a CMake build system, and optional inclusion of the AMPL GSL bindings so that GSL functions can be accessed from AMPL, with the bindings documented separately on the readthedocs site for amplgsl. That framing matters for everything else on this page. This is not a fork with a diverged codebase, it is the upstream release plus a build system wrapper and a set of bindings, so the numerical code you are compiling is the GNU code, and the licensing, the bug list and the release cadence are the GNU ones. The repository listing bears that out. Alongside the CMakeLists.txt and the cmake directory there is the full autotools machinery, configure, configure.ac, Makefile.am and aclocal.m4, the standard GSL source directories such as blas, cblas, fft, filter, fit, deriv, eigen, bspline, block and const, and the usual project files including COPYING, ChangeLog, NEWS, BUGS, INSTALL and THANKS. There is also CI and packaging infrastructure that upstream does not ship in this form, an Azure pipeline definition, a codecov configuration, and NuGet packaging scripts and specifications for building GSL with MSVC on x86 and x64.

Building with the AMPL bindings starts with a submodule

The bindings path has one prerequisite that is easy to miss, and the README puts it as step one: make sure that the ASL submodule is initialised, in the ampl/thirdparty/asl directory. The repository carries a .gitmodules file, so a fresh clone without submodule initialisation will not build this path, and the error will point at a missing directory rather than at the build script. The rest is the standard CMake dance, and the README gives the exact commands, starting with creating a build directory and moving into it.

   mkdir build
   cd build

Then you initialise the build files with the generator of your choice, and the example in the README is the Unix Makefiles generator.

   cmake .. -G"Unix Makefiles"

And then you build the resulting build files.

   make .

The point of doing this through CMake rather than the GNU autotools path is portability. The GSL distribution is built with configure and make and expects a Unix style environment, while a CMake build drops into an existing build system, an IDE, a continuous integration pipeline, or a toolchain such as a Windows compiler, without anyone having to translate the autotools rules by hand. If you are an AMPL shop, the bindings are the reason to be here rather than to take the plain GNU tarball.

The no-bindings build and the subset build option

The second path skips the bindings entirely with a single definition, and the README's example shows the variable placed after the generator.

   cmake .. -G"Unix Makefiles" -DNO_AMPL_BINDINGS=1

That is the build you want if you only need the C library and the numerical routines. The more interesting option is the third, which the README describes as experimental support to build only a subset of the GSL library. You define a variable called BUILDLIBS when calling CMake, and its value is a comma separated list of GSL directories.

   cmake .. -DBUILDLIBS=ode-initval2,linalg -DNO_AMPL_BINDINGS=1

The example builds the initial value ODE modules and the linear algebra modules and nothing else, which for a project that only needs those routines is a real reduction in build time and in the size of the artefact. Two conditions apply and both are stated. The subset build is only supported when the AMPL bindings are not being built, which is why the example passes NO_AMPL_BINDINGS, and the tests often carry extra dependencies, so the README recommends disabling them to get the full benefit, and shows the combined invocation.

   cmake .. -DBUILDLIBS=ode-initval2,linalg -DNO_AMPL_BINDINGS=1 -DGSL_DISABLE_TESTS=1

Turning off the documentation is the same shape of switch, with DOCUMENTATION set to OFF.

   cmake .. -DDOCUMENTATION=OFF

The README also says that all the dependencies are handled automatically, which is the practical benefit of the CMake route over working with the autotools output directly.

Where the canonical release actually lives

The repository is careful about the distinction between itself and the upstream project, and a reader who misses that will make the wrong assumptions. The availability section states that the current stable version of GSL is always available from ftp.gnu.org in the /pub/gnu/gsl directory, with a list of mirror sites linked from the GNU ordering page. The project homepage given in the README is the GNU one at gnu.org/software/gsl, and the NEWS file is where recent changes to the library are recorded, with a GSL reference manual by Galassi and colleagues, second revised edition, ISBN 0954161734, 620 pages, that can be ordered from bookstores, with a Japanese translation available from the project website. The money raised from the manual supports the development of the library, which is a detail worth knowing if you are reading the documentation and wondering how it is funded. The homepage for this particular repository is gsl.ampl.com, and the only release listed for it is AMPLGSL v20211111 from 2021-11-11, so the bindings have their own version line, separate from the GSL release they wrap. The last push to the repository was on 2026-05-19, so the mirror is being refreshed even though the bindings version has not moved since 2021.

GPL-3.0 and the proprietary use question

The licence section of the README is short and has one sentence that decides commercial cases. GSL is free software, you can redistribute it and modify it under the terms of the GNU General Public License, and the GPL does not permit this software to be redistributed in proprietary programs. The rest is the standard disclaimer that the library is distributed in the hope that it will be useful but without any warranty, and the repository carries the COPYING file with the licence text. The practical reading is that linking GSL into a closed source product is the case to think about carefully, and that the obligation attaches to the library, not to the CMake wrapper or the AMPL bindings, so the wrapper does not make the underlying GPL terms disappear. For a team that only uses GSL internally, the licence is not a barrier. For a team shipping a proprietary binary that includes GSL code, it is, and the answer is not in this repository. The same reasoning applies to the bindings, which are the part this repository adds on top, and it is worth noting that the bindings are also covered by the licensing of the code they expose, since calling a GPL routine from a model does not change the terms of the routine itself.

Reporting bugs, and the upstream contribution path

The bug reporting guidance in the README is worth reading closely, because it tells you where a problem actually has to go. A list of known bugs can be found in the BUGS file, and details of compilation problems in the INSTALL file, and if you find a bug which is not listed in those files the README asks you to report it to [email protected]. The address is the GNU one, not the AMPL one, which is the clearest signal about where authority sits. The README also lists what a good report contains, and the list is instructive because it is a template for a report that can be acted on. It asks for the version number of GSL and where you obtained it, the hardware and operating system, the compiler used including its version number and compilation options, a description of the bug behaviour, and a short program which reproducibly exercises the bug. It also asks whether the same problem occurs when the library is compiled without optimization, which separates a numerical sensitivity problem from a logic problem. Errors or omissions in the manual can also be reported to the same address, and the INSTALL file is where you should look for platform and compiler specific notes, including a Compilation Notes section, since the README points you there rather than repeating it. For contributors, the README points at the GSL development webpage.

Editorial conclusion

Adopt ampl/gsl if you want the GNU Scientific Library with a CMake based build, particularly if you are inside an AMPL toolchain and need the bindings to reach GSL functions from a model. It does not fit a proprietary product, because the README states the GPL does not permit redistribution of this software in proprietary programs, and it does not fit a team that wants the canonical GNU release, since the README points the stable version to ftp.gnu.org and this copy is a mirror with additions. Before you build, confirm that the ASL submodule is initialised if you are enabling the AMPL bindings, and check whether the GSL source tree you need is already in your distribution before taking the subset build path.

Frequently asked questions

Official sources

1. ampl/gsl on GitHub
2. License: GPL-3.0
3. Project website
4. README
5. Releases