Hi Matthias,

I looked into cross building lapack and that mostly works except that
dpkg-shlibdeps fails to find libgfortran.so. I looked and there is a
subtle cross/native difference at play here. The native
gfortran-PV-arch_gnusuffix built from gcc-PV depends on
libgfortran-PV-dev whereas the cross toolchain
gfortran-PV-arch_gnusuffix built from gcc-PV-cross depends on
libgfortran-PV-dev-ARCH-cross. I think this is right as the cross
toolchain cannot issue cross-architecture dependencies. Still this means
that when using a cross toolchain, libgfortran.so is placed in
/usr/triplet and not found by dpkg-shlibdeps. Really though when
depending on gfortran-for-host, I want to expect that dpkg-shlibdeps
just works on generated binaries. I propose that we duplicate the
libgfortran-PV-dev dependency issued from the native toolchain
gfortran-PV-arch_gnusuffix into the gfortran-PV-for-host package. In the
native case, it will be satisfied already and in the cross case it will
pull the library that makes dpkg-shlibdeps happy. I'm attaching the
obvious patch for your convenience.

Helmut

Control: tags -1 + moreinfo

why is this necessary, compared to e.g. g++-14-for-host? and why is this
only necessary for gfortran-for-host?

Please note, that no .so symlink is installed into /lib or /lib/<ma>,
everything is installed into the gcc_lib_dir, to be able to install
multiple GCC versions in parallel. That's a design decision made 20
years ago, so I'm still trying to figure out what problem you are trying
to solve.