FLINT: number theory arithmetic in C, built for exactness

A library that is also a research project

The README defines FLINT twice on purpose. It is a C library in support of computations in number theory, and it is also a research project into algorithms in number theory. Both descriptions are load bearing, because the library and the algorithms advance together and the code you call is often the newest version of a method that appeared in a paper.

The scope is broad but concrete. FLINT consists mainly of fast scalar and polynomial arithmetic, factorization and linear algebra over many basic rings, which the overview lists as integers, rationals, reals, finite fields, number fields and p-adics. On top of that sits some higher-level functionality for algebraic and analytic number theory.

The repository topics match that list closely, with arbitrary-precision-arithmetic, computer-algebra, factorization, linear-algebra, number-theory and polynomial-arithmetic. The homepage is flintlib.org, there is a mailing list on Google Groups for developer discussion, and the online documentation lives at flintlib.org/doc.

For a reader deciding whether to adopt it, the important question is what it replaces. If your program needs to factor a 200 digit integer, or multiply polynomials over a number field, or solve a linear system exactly over the rationals, then FLINT is the layer that turns an academic exercise into a function call, at the price of a C dependency that has to be built and installed.

Version 3 absorbed four separate libraries

The version history explains a lot about the current codebase. FLINT 2, released in 2011, was a complete rewrite of FLINT 1.x from scratch. FLINT 3, released in 2023, incorporated the Arb, Antic, Calcium and Generic-Rings libraries, which had previously been developed separately.

That merge is visible in the way the library presents itself today. Arb, from the arblib.org project, and Antic are part of the Flint organisation, while Calcium and Generic-Rings come from Fredrik Johansson, who is now the project leader. A single tree now covers exact arithmetic, ball arithmetic and the ring abstractions that used to live in separate code bases with their own release cycles.

The release line since then has been steady. v3.4.0 shipped on 2025-11-25, v3.5.0 on 2026-04-24 and v3.6.0 on 2026-06-29, with the last push to the repository on 2026-10-18. Minor version numbers in a library of this size usually mean an API has moved, so an upgrade is worth reading rather than assuming.

The deprecations.txt file at the top of the repository is the concrete artefact of that churn. It is the place to look before you upgrade, since it records what has been deprecated and, in a library that renames types as its abstractions shift, which names you should stop using.

Building from source with the GNU build system

The README gives a complete from source build, and it is worth following literally because the dependencies are easy to miss.

The example assumes GMP, MPFR and the GNU build system are already installed. On Ubuntu they are installed with:

    apt install libgmp-dev libmpfr-dev make autoconf libtool-bin

possibly with super-user privileges. GMP provides the underlying multiple precision integers, and MPFR the multiple precision floating point layer, so this is a source build with two compiled dependencies in front of it.

The full sequence, from a fresh clone to installed documentation, is:

    git clone https://github.com/flintlib/flint.git && cd flint
    ./bootstrap.sh
    ./configure                        # ./configure --help for more options
    make
    make check                         # optional
    make install                       # optional
    make examples                      # optional
    cd doc && make html && cd ..       # optional: documentation

Four of those steps are marked optional, and each one is a separate decision. make check runs the test suite, make install puts the library and headers on the system, make examples builds the sample programs, and the last line builds the HTML documentation locally. The configure line has a comment pointing at --help for further options.

There is no binary package path described in the README, and no mention of a container image. If your build pipeline expects a package manager artifact, you will be compiling this from source, which for a library of this size is a real operational cost.

Two build systems and the packaging files

The repository layout shows that FLINT is not tied to the autotools path alone. There is a CMake/ directory and a CMakeLists.txt at the top level, alongside Makefile.in, configure.ac, acinclude.m4, a config/ directory and bootstrap.sh. There are also two packaging templates, flint.pc.in for the pkg-config path and flintConfig.cmake.in for the CMake path, which tells you that both integration routes are supported rather than one being a leftover.

The remaining top level files are the ones a contributor needs. INSTALL.md is the extended installation guide, code_conventions.md is the style guide for the codebase, deprecations.txt records the deprecations, and the AUTHORS file holds the contributor list. VERSION holds the version string, and COPYING and COPYING.LESSER hold the licence text, the latter two matching the LGPL terms the README describes.

The other directories are the library's own structure: src/ for the sources, doc/ for the documentation sources, examples/ for the sample programs, and dev/ for developer tooling. The continuous integration badge points at a CI workflow, and there is a separate coverage badge, so the test suite and coverage measurement are part of the normal loop rather than something a maintainer runs occasionally.

The examples directory is the API in miniature

The examples folder is a better orientation aid than the documentation index, because every file names a specific capability. The listing runs from the elementary to the specialised.

At one end there are primality and factorisation, with check_n_is_prime.c and factor_integer.c alongside factor_polynomial.c and fmpz_poly_factor_zassenhaus.c, the last being the Zassenhaus variant of polynomial factorisation over the integers. Beside them sit fmpz_poly_hensel_P1 for Hensel lifting, fmpz_poly_q.c, fmpz_mod_poly.c and fmpq_poly.c for the module and rational polynomial types, and fq_poly.c for finite fields.

Then there are the analytic and algebraic pieces: bernoulli.c, binet.c, delta_qexp.c, class_poly.c for class field theory, and integrals.c. Elementary linear algebra shows up as hilbert_matrix.c and hilbert_matrix_ca.c, the second presumably the certified version given the suffix. groebner.c covers Groebner bases, dft.c the discrete Fourier transform, crt.c the Chinese remainder theorem, and huge_expr.c very large expressions.

Two files are about the library rather than the mathematics. fpwrap.c wraps floating point behaviour, and functions_benchmark.c is a benchmark harness, which is a useful signal about how the project treats performance: it ships the tooling to measure it, so claims about a routine being fast are checkable by the reader rather than taken on trust.

Maintainership has changed hands twice

The authorship section of the README is a good short history. FLINT was started in 2007 by David Harvey and William Hart, and maintenance was later taken over solely by William Hart, who remained in charge of the project until 2022.

The current maintainers are Fredrik Johansson, listed as project leader since 2022, and Albin Ahlbäck. A large number of authors have contributed over the years, with a complete list at flintlib.org/authors.html and in the AUTHORS file.

Two implications follow for an adopter. The first is that the project has survived a leadership handover, which for a C library with a large API is a meaningful signal about whether the codebase is institutional enough to outlive its maintainers. The second is that the current lineage runs through the author of two of the libraries merged into FLINT 3, Calcium and Generic-Rings, so the direction of the project is closely tied to that line of work on rings and special functions.

For contributions, the repository has a CODE_OF_CONDUCT-style governance file referenced by the broader GitHub organisation conventions, and the practical entry points for discussion are the flint-devel mailing list and the issue tracker on the repository. A large research codebase is easier to contribute to when there is a public place to ask questions before writing a patch.

LGPL-3.0, and what that asks of a distributor

FLINT is distributed under the GNU Lesser General Public License, version 3 or later, and the README points at the COPYING.LESSER and COPYING files that hold the text. This is a library licence rather than a copyleft licence for the whole of your program, and the distinction is the whole point of the LGPL.

The general shape is that you can link FLINT into your own software and distribute the result, and that modifications to FLINT itself, if you make any, must be released under the same terms. Depending on how you distribute, the LGPL also carries requirements around providing the library source or an offer for it, and around relinking in the case of a modified shared library. Those are the conditions to check against the COPYING files, and this is not advice about them, since the right answer depends on how your product is shipped.

For an organisation that already ships GPL-compatible or LGPL-compatible components, this is an ordinary requirement. For a commercial product that avoids copyleft in its own codebase, the LGPL is chosen precisely so that dynamic linking to FLINT is possible, and the practical advice is to read the licence text carefully and to keep the build arrangement, in particular whether FLINT is a shared or static library, consistent with how you intend to distribute.

The dependencies matter for the same reason. GMP and MPFR are present in the build, so their own licensing terms apply to the combined distribution as well.

Editorial conclusion

Adopt FLINT if you are writing C code that needs exact integer, polynomial, matrix or algebraic number arithmetic and would rather not implement it, and if you are willing to depend on GMP and MPFR being present on the build host. Skip it if your work is floating point analysis where the platform library is enough, or if a from source build is not an option for your pipeline, since the README documents no binary package path. Before you start, read INSTALL.md and the online documentation at flintlib.org/doc, decide between the GNU build system and the CMake files in the repository, and check the COPYING and COPYING.LESSER files for the LGPL obligations that apply to your distribution. The last push was on 2026-10-18 and v3.6.0 was released on 2026-06-29.

Frequently asked questions

Official sources

1. flintlib/flint on GitHub
2. License: LGPL-3.0
3. Project website
4. README
5. Releases