Re: How to deal with gfortran dependencies?
On 02/11/2024 16:14, Drew Parsons wrote:
On 2024-11-02 14:55, Matthias Klose wrote:
A lot of the fortran packing, including the module provisions were
suggested and are maintained (?) by other Debian developers, some of
them from the science team. It would make sense to include these
people into the discussions as well.
To make matters worse, the actual gfortran dependency of libopenmpi-dev
is emitted from dh-fortran-mod. If we were to change dh-fortran-mod to
change fortran:Depends to emit gfortran-for-host right now, a lot of
packages would FTBFS as they'd expect gfortran and only find
<triplet>-gfortran.
Helmut
I realise I haven't explained the developments I was doing with
dh-fortran-mod to Debian lists before (only some one-to-one discussions)
so to summarise:
I have been testing out ideas (mostly in experimental, and the
dev-multifortran branches of some packages) that I was hoping to have
ready for Debconf and discuss them there as a proposal. That didn't
happen; the work is stalled and will not happen in time for Trixie; I'm
working on MPI transitions and gcc14 FTBFS on 32-bit packages instead.
It is motivated by the fact we now have multiple Fortran compilers, not
just gfortran.
The idea is to rebuild dh-fortran-mod into dh-fortran: a set of deb
helper tools that would enable parallel Fortran library environments,
so that you could either enable a set of Fortran compilers to support
multiple compilers, and ideally also do:
$ FC=newfc dpkg-buildpackage
and rebuild a complete stack of library packages in an automated manner.
Under the hood, the idea is that libraries get rebuilt and renamed so
(1) $(LIBDIR)/libfiat.so.0.1 -> $(LIBDIR)/libfiat-gfortran.so.0.1
(2) The internal SONAME gets changed to libfiat-gfortran.so.0
(3) The devel symlink moves:
$(LIBDIR)/libfiat.so --> $(LIBDIR)/fortran/gfortran/libfiat.so
Similarly for the modfiles (pre-compiled headers). There is more to it
than that - pkgconfig file, cmake, etc need work but thats what i'm
working on.
Locally I'm working on gfortran, flang-new, flang-to-external-fc,
lfortran (in packaging now), and exploring others (including some
proprietary and other changes at work).
I work in code optimisation in the meteorology community and we're
seeing an explosion of interest in Fortran and compiler changes: the
meteorologists are still writing new Fortran (its an easy to understand
language for their field) while for code optimisation the effort has
moved from hand-optimising the code (for OpenMP and OpenACC) to
whole-stack compiler improvements with LLVM etc and source-to-source
translators.
The challenge is being able to rebuild the whole stack for a new
compiler, hence the need to develop better conventions in this area and
cleanup compiler-specific issues in the codebase and build tools. We're
now running our codes in containers on HPC machines, meaning I can build
the models I'm working on in a Debian Docker container with most of the
stack from base Debian and the library stack in up to 10-deep in places.
Key here is that this is a long-term effort that:
(1) I don't propose changing the default compiler on Debian
(2) Changes should not break existing stuff.
--
Alastair McKinstry,
GPG: 82383CE9165B347C787081A2CBE6BB4E5D9AD3A5
e: alastair@mckinstry.ie, im: @alastair:mckinstry.ie @amckinstry@mastodon.ie
Commander Vimes didn’t like the phrase “The innocent have nothing to fear,”
believing the innocent had everything to fear, mostly from the guilty but in the longer term
even more from those who say things like “The innocent have nothing to fear.”
- T. Pratchett, Snuff
Reply to: