Re: Bug#993031: ripser FTCBFS: hard codes the build architecture compiler
Hi Gard,
On Thu, Aug 26, 2021 at 11:10:32PM +0200, Gard Spreemann wrote:
> Thanks a lot for making me aware of this. The package above has been
> fixed, but I know I have a similar problem with a Fortran (77) package I
> maintain (src:lbfgsb). I tried the same recipe there, letting
> buildtools.mk set FC in that case. However, it sets it to
> x86_64-linux-gnu-f77 and the likes, which doesn't seem to be provided by
> any package (or am I blind?). Do you have some advice for me in this
> regard?
I fear that we cannot provide a solution for fortran at present. There
seem to be multiple issues at present.
For one thing, a fortran compiler is not build-essential so you have to
depend on it. Typically and in case of src:lbfgsb, you add gfortran to
Build-Depends. This dependency is not satisfiable during cross
compilation. The issue is known and tracked as #666743. More review and
testing is needed here. Once that bug is fixed, you should change the
gfortran dependency to gfortran-for-host.
Then, it seems that dpkg's buildtools.mk disagrees with gcc on how the
fortran compiler is called. It seems like /usr/bin/f77 is managed using
alternatives. Is it intentional that we use that path during builds or
would you rather force gfortran given that you depend on gfortran rather
than flang?
If the alternatives still make sense today, gcc should likely provide
triplet-prefixed alternatives as well. On the other hand, if everyone
expects f77 to be gfortran, the alternative should be removed and
replaced by a simple symlink.
Depending on the outcome, maybe dpkg's buildtools.mk should be changed
to use gfortran as the tool name instead of f77.
Can you provide more background on the fortran situation?
In any case, #666743 will need to be fixed before we can make a dent
here.
Helmut
Reply to: