Cross compiling fortran packages

[Helmut Grohne]

Hello,

Alastair and myself managed to sit down for an hour discussions the 
intersection of Fortran and cross compilation. This mail tries to 
summarize some of the insights and agreements gained. If anyone 
disagrees with any of the outcomes, please speak up.

Alastair wants to enable the use of more Fortran compilers. In doing so, 
he terms "vendor" a toolchain origin such as gfortran or flang. He terms 
"flavor" a major version of a toolchain such as gfortran-14 or flang-19. 
A flavour implies a particular vendor.

In doing so, the FC environment variable becomes both responsible for 
communicating the host architecture and the flavor to the upstream 
build. A Debian package builder shall continue to be able to choose the 
toolchain via the FC variable, but we also want to offer a way to choose 
the flavor independently of the host architecture. The way to select 
that is not settled yet. It also is not clear whether the -target option 
passed to flang belongs to the FC variable or the FCFLAGS variable from 
an upstream point of view and we deferred that question in favour of 
looking for prior art. As a result, we intend to not support cross 
compilation with flang initially.

Fortran compiler flags are dependent on both the host architecture and 
the desired Fortran flavor. We'll have to work with Guillem to figure 
out how to make this work as intended.

Alastair proposed a filesystem layout that uses both 
architecture-dependent (LIBDIR=/usr/lib/${DEB_HOST_MULTIARCH}) and 
flavor or vendor dependent (as appropriate) filenames. This generally 
suits well with multiarch and cross building.

When it comes to Build-Depends, the current practice poses problems to 
cross building. dh-fortran-mod is M-A:foreign and Depends on gfortran | 
fortran-compiler. This violates what is supposed to become Debian policy 
and also is not useful for cross compilation. The foreign Multi-Arch 
value causes the chain to install the build architecture Fortran 
compiler which most of the time is not what we wanted. We agreed that 
dh-fortran-mod should do one of two options in forky:

A. Drop the dependency on gfortran. Instead, packages using 
   dh-fortran-mod should depend directly.
B. Turn the dh-fortran-mod package Architecture: any and change its
   Multi-Arch value to either "no" or probably "same" (up to discussion).

Generally, a dependency on gfortran will request the gfortran compiler 
targeting the implied architecture as an executable of the implied 
architecture. As the implied architecture is the host architecture, this 
tends to not give us a Fortran compiler that can be executed when doing 
cross builds. We want to move to the "-for-host" and "-for-build" 
variants that describe what architecture the toolchain is used for. Most 
of the time, a gfortran dependency will become gfortran-for-host. That 
may also apply to dh-fortran-mod if it keeps the dependency.

As we move to gfortran-for-host, we must pay attention to the fact that 
/usr/bin/gfortran will be unavailable during native builds. Instead 
${DEB_HOST_GNU_TYPE}-gfortran should be used for execution. This is what 
/usr/share/dpkg/buildtools.mk initializes FC to already. The reason for 
this is another use case where we'd like to be able to install a 32bit 
toolchain running as a 64bit executable in a 32bit chroot to avoid 
issues with address space exhaustion during build (e.g. an armhf chroot 
containing g++-arm-linux-gnueabihf:arm64). There is no sensible way to 
provide the unprefixed tool name and hence uses of -for-host packages 
generally must ensure that triplet-prefixed tools are used even for 
native builds. This fully affects Fortran packages as unprefixed 
gfortran typically becomes unavailable once switching the Build-Depends.

This is my cross-focused recollection of what we discussed. For more 
background on the Fortran side, refer to
 * https://debconf25.debconf.org/talks/7-fortran-policy-for-debian/
 * https://meetings-archive.debian.net/pub/debian-meetings/2025/DebConf25/ 
   video not yet available at the time of this writing, but likely 
   soon

I hope that Alastair replies and corrects the things I got wrong and 
extends the pieces I got missing.

Helmut