# A Fortran Policy for Debian

Alastair McKinstry

► To cite this version:

Alastair McKinstry. A Fortran Policy for Debian. DebConf25, IRISA, Jul 2025, Brest, France. pp.9. hal-05334565

HAL Id: hal-05334565

https://hal.science/hal-05334565v1

Submitted on 28 Oct 2025

HAL is a multi-disciplinary open access
archive for the deposit and dissemination of sci-
entific research documents, whether they are pub-
lished or not. The documents may come from
teaching and research institutions in France or
abroad, or from public or private research centers.

L'archive ouverte pluridisciplinaire HAL, est
destinée au dépôt et à la diffusion de documents
scientifiques de niveau recherche, publiés ou non,
émanant des établissements d'enseignement et de
recherche français ou étrangers, des laboratoires
publics ou privés.

<figure><img src="image_1.png" /></figure>

Distributed under a Creative Commons Attribution 4.0 International License
# A Fortran Policy for Debian

Alastair McKinstry

Irish Centre for High-End Computing

University of Galway

Galway, Ireland H91 TK33

Email: amckinson@ichec.ie

**Abstract**—With the arrival of Flang and LLVM-based compilers there are now multiple Fortran compilers realistically available in Debian Linux. However they cannot be safely mixed, due to incompatible precompiled modules and ABI issues. This paper describes current work to support multiple Fortran compilers in parallel in Debian, and a proposed policy for Fortran packages and libraries.

Fortran, gfortran, LLVM, lfortran, Debian, Linux

## I. INTRODUCTION

Fortran is currently undergoing a renaissance [1]. It is a small language (a 10th the size of C++) ideally suited for array-oriented scientific calculations. Features such as co-arrays and DO CONCURRENT enable automatic optimisation by compilers for parallel systems and accelerators such as GPUs. This potential has been stymied for years by a lack of compiler development. This is now changing due to the LLVM compiler technologies.

Secondly, Fortran has a large number of working, debugged, numerical libraries that are optimised and freely available. This means that there is a need to be able to compile an existing application or library with a new compiler with ideally no code changes.

This is especially true when there is a “stack” of libraries involved; in the Debian Trixie codebase some packages have library dependency graph depth 12-deep. These may all need to be compiled with the same compiler; important libraries should support as many compilers as possible automatically.

So, the aim of this work is to define a Fortran policy and set of support tools that make it possible to execute

FC=newfort dpkg-buildpackage mypackage.dsc

and produce a new package compiled with the new compiler. Ideally it should be possible to compile a library package with support for multiple compilers.

## II. FORTRAN COMPILER DIFFERENCES

For Fortran libraries<fnref n="1" /> supplied in `-dev` development packages in Debian, differ in two important manners: the pre-defined includes files (modules) and the Library ABIs. Additionally, they may take different command-line flags and environmental variable settings.

### A. Module files

Fortran allows code to be structured in modules and sub-modules [6] which are interface definitions similar to header files in C/C++. These files typically have a `.mod` or `.smod` suffix, but the contents are compiler-dependent and can depend on the version of the compiler. Hence to support multiple compilers, module files will need to be stored in compiler-dependent directories.

For example:

<figure><img src="image_2.png" /></figure>

Because module files may differ across compiler versions, a library package may be built several times to generate the necessary module files (i.e. in different build directories `build-gfortran14`, `build-gfortran15`, etc.) and module files be packaged for each flavour.

### B. Library ABIs

Compilers typically provide code that is ABI-compatible even when module files are not; e.g. code produced by `gfortran-14` and `gfortran-15` can be ABI-compatible, while `gfortran` and `flang` code may not be. Hence it is useful to distinguish between a compiler flavour (e.g. `gfortran14`) and compiler family (`gfortran`, `flang`).

To support co-installability, shared libraries need to be named with a prefix for the ABI family. So for a library package `fkit`, there may be shared libraries:

<figure><img src="image_3.png" /></figure>

These libraries will have the ELF SONAMES set accordingly.

## III. EXISTING WORK

GNU Make (used in the Debian build file `debian/rules`) supports the variables `F77` and `FC` for FORTRAN-77 and default Fortran (F9x and beyond) respectively.

In Debian, the alternatives system [2] enables packages to provide multiple alternative default compilers for Fortran, using the aliases (`symlinks`) `/etc/alternatives/f77` and

<footnote n="1">¹In this work, “Fortran libraries” means Fortran code compiled to a library for other applications to link against, rather than code shipped by the compiler itself</footnote>
/etc/alternatives/f95.

Several packages and frameworks use the configuration or
environment variables FMODDIR and FLIBDIR for Fortran include
and library directory paths respectively. These should be used if
defined.

The include file buildflags.mk in debhelper defines build
flags used. Relevant are that FFLAGS, FCFLAGS and LDFLAGS are
defined (for the host compiler) along with*_FOR_BUILD variants
for the build compiler. These typically need to be changed for non-
gfortran/gcc compilers.

IV. SUPPORTING INSTALLATION AND BUILDS

This section describes experimental support in the Debian pack-
age dh-fortran-mod (being renamed dh-fortran) to enable
transparent build for multiple compilers.

The package provides the Debhelper commands [3]
dh_fortran_mod and dh_fortran_lib and a set of
Makefile macros and variables in the include file

/usr/share/debhelper/fortran/fortran-support.mk

Collectively they should make it possible to build a Fortran
library package without hard-coded references or assumptions of the
compiler variant used. It is proposed that these debhelper functions
be the recommended way to install module files and Fortran libraries.

A. Proposed File layout

The proposed policy follows existing practice for co-installed
libraries used in e.g. the HDF5 library. HDF5 provides multiple
variants: "serial", "openmpi" and "mpich". In HDF5, the following
structure is used:

<figure><img src="image_4.png" /></figure>

This enables the filetree to be passed to a build system for a
dependent-package to use HDF5 in a variant-transparent way, e.g.

./configure ... --with-hdf5=${LIBDIR}/hdf5/serial

The resulting library or executable will be linked with the SON-
AME libhdf5_serialh1_fortran.so.310, which is dis-
coverable in ${LIBDIR}.

The plan then is to provide a file layout that enables existing build
systems to be iterated over with a number of compiler flavours, with
helper scripts handling the mangling of filepaths and some changes
to build tools that build systems such as GNU configure and CMake
may call.

B. dh_fortran_mod and dh_fortran_lib

These commands are Debhelper utility functions that take the path
to a module file or library file respectively, and install the file in the
appropriate place with any necessary symlinks.

For example:

dh_fortran_mod ./debian/tmp/include/fckit.mod

will install the module file

${LIBDIR}/fortran/gfortran-mod-15/fckit.mod

(the variant being detected automatically).

dh_fortran_lib --flavor=gfortran \
./debian/tmp/lib/libfckit.so.0d fckit

will install the shared library in

${LIBDIR}/libfckit-gfortran.so.0d

with symlinks from

${LIBDIR}/fortran/gfortran/libfckit.so

and

${LIBDIR}/fckit/gfortran/libfckit.so

with the SONAME in the shared library being edited accordingly.

C. fortran-support.mk

fortran-support.mk is an include file for debian/rules
to enable building packages for multiple Fortrans.

It defines two variables for Makefile usage: FC_DEFAULT and FC_OPTIONAL, defining the (required) FC default compiler flavour and the flavours of optional compilers that are present on the system.

The expected usage is (in current experimental configuration) is
that a library package will build successfully for the compiler set
as FC_DEFAULT or the build will fail, while a build will attempt
to compile and build for the FC_OPTIONAL compilers, and will
include those if successful.

Debian build systems define a number of stages for pack-
age construction: configure, build, and install; Debhelper pro-
vides a set of macros for support in each of these stages (e.g.
dh_auto configure). The aim of the fortran-support code is to
extend each of these targets for each compiler, with the following
pattern:

define dh�ropartypart
    dh_configure_fortran_$(1):
        dh_auto_configure \
        --builddirectory=$debiandebuild-$(1) \
        -- ${BUILD_FLAGS} \
        -DCMAKE_Fortran_COMPILER=$(call get_fc_exe, $(1)) \
        -DCMAKE_Fortran_FLAGS="$(call get_fcflags, $(1))"
endef
$(eval $(call foreach_fc_execute_before,configure))

i.e. template code is added for each stage (which can be
over-ridden, following debhelper conventions), with the targets
dh_${STAGE}_fortran_${COMPILER} being called for each
compiler.

Hence the build system gets called multiple times for each available
compiler (where FC_OPTIONAL is set) with the appropriate flags,
etc. All compiler (and compiler-version) specific definitions are
limited to the dh-fortran package.

D. Flag handling

FFLAGS and FCFLAGS are already defined via
buildflags.mk and elsewhere but typically contain settings that
are gfortran-specific (and even specific to a given version). For
example, currently (Debian 12) -fstack-clash-protection
is defined which breaks on flang. Hence this needs to be removed
on flang builds.

Similarly, many legacy codes which otherwise work now
break on gfortran > 9 unless -fallow-invalid-boz<fnref n="2" /> and

<footnote n="2">²Allows deprecated hexadecimal BOZ literal constants to be specified using the 'X' prefix</footnote>
`-fallow-argument-mismatch`<fnref n="3" /> are defined (work is needed on the legacy codes to bring them to standard).

So in `fortran-support.mk`, macros `get_fcflags` and `get_fflags` taking the compiler flavour are defined, which internally uses variables:

```
FCFLAGS_ADD_GFORTRAN14:= -fallow-invalid-boz \
                       -fallow-argument-mismatch
FCFLAGS_ADD_GFORTRAN15:= -fallow-valid-boz \
                       -fallow-argument-mismatch
...
```

```
FCFLAGS_FILTER_FLANG7:= -g
FCFLAGS_FILTER_FLANG18:= -fstack-protector-strong \
                       -fstack-clash-protection ...
...
```

where sets of flags that will be added to, or filtered from, `FCFLAGS` and `FFLAGS` for each Fortran flavour.

## V. SUPPORTING BUILD SYSTEMS

This section describes the recommended changes and conventions that should be adopted for several build tools to make this happen.

### A. pkg-config files

`pkg-config` provides compiler and linker flags for development frameworks. These may need to be different for different compilers.

To support this, it is proposed to use the `--define-variable` CLI parameter to pass the value of `fortran`, set as the basename of the compiler e.g.

```
pkg-config --define-variable="fortran=gfortran-14" \
           --libs fckit
```

The variable `fortran` should be defined in any relevant `.pc` file.

This will enable the construction of variables within the `pkg-config` file and where necessary the conditional inclusion of further `pkg-config` file fragments.

### B. CMake configuration files

The CMake build system makes use of file fragments installed by dependency packages to provide configuration information.

CMake files (typically installed by `dev` packages in `$LIBDIR`)/`cmake`/$PKGNAME`) have hard-coded paths for directories and files, and CMake is sensitive to those paths existing. Hence there needs to be multiple such files for each variant.

It is recommended that the convention used in `boost`, where variants for different flavours are named `libboostcontainer-variant-shared.cmake` and `libboostcontainer-variant-static.cmake` be followed.

## VI. GENERAL RECOMMENDATIONS

* All build systems should enable out-of-source builds, to allow multiple builds with different compiler options.

* Fortran compatibility libraries (wrappers to other libraries) should either be well-defined submodules of a package that can be called independently to allow rebuild without rebuilding the whole package, or a separate package.

* It should be possible to overrule Fortran build flags with environmental variables or build options.

* Build systems should support the environmental variables `FLIBDIR`, `FMODDIR`, `FCFLAGS`, and `FCFLAGS` if defined.

* Wrapper codes such as `f2py` (part of ` numpy`) should be stand-alone packages to enable rapid iteration with new compilers.

## VII. OPEN QUESTIONS

* Should we expose the Fortran library types in the package metadata? e.g. either rename a package `libfckit-0d` to `libfckit-0d-gfortran` or add a `Provides:` entry to the metadata provided ?

* How should environmental variables such as `FCFLAGS`, constructed and altered by multiple Makefile includes fragments, be handled?

## VIII. CONCLUSIONS

By adopting the file layout and shared library mangling changes described, it is possible to provide multiple-compiler support for Fortran in Linux, in a manner that enables new compilers to be supported without changes to the packages. Work remains to add more support in debhelper and in adapting build tools.

This then enables a deep library stack to be recompiled for new compilers and so makes compiler improvements worthwhile as the changes will improve and impact the whole distribution.

## REFERENCES

[1] P. Krill, *Fortran popularity rises with numerical and scientific computing*, https://www.infoworld.com/article/2337114/fortran-popularity-rises-with-numerical-and-scientific-computing.html, 2024.

[2] Debian, *The Debian Policy Manual*, v4.7.2, https://www.debian.org/doc/debian-policy/ap-pkg-alternatives.html, 2025.

[3] J. Hess et al. *Debhelper*, v13 https://manpages.debian.org/bookworm/debhelper/debhelper.7.en.html, 2025.

[4] The Flang Team, *The Flang Compiler*, https://flang.llvm.org/docs/, 2025

[5] D. Spickett, *LLVM Fortran Levels Up: Goodbye flang-new, Hello flang!*, https://blog.llvm.org/posts/2025-03-11-flang-new/, 2025

[6] ISO, *ISO/IEC TR 19767:2005 Fortran - Enhanced Module Facilities*. ftp://ftp.nag.co.uk/sc22wg5/N1601-N1650/N1602.pdf, 2025

<footnote n="3">³Allows unsafe casting of types in older standards</footnote>