On Friday, July 08, 2022 08:12 AM MDT, Khem Raj <raj.khem@...> wrote:

On Fri, Jul 8, 2022 at 2:25 AM Gregory Anders <greg@...> wrote:

On Thu, 07 Jul 2022 16:26 +0100, Richard Purdie wrote:

On Thu, 2022-07-07 at 06:39 -0700, Gregory Anders wrote:

Problem solved: the issue was actually that I was using a network
sstate cache,
and the cached output of gcc-cross did not contain gfortran.
Disabling the
sstate cache for gcc-cross causes gfortran to be included in the
sysroot and
now all is working as expected.

You shouldn't have to disable the sstate cache but glad you got it
working. Which release series is that with?

I am using Xilinx's Petalinux tool, which uses honister under the
hood. Xilinx maintains an sstate cache for Petalinux, which is quite
convenient for cutting down build times, but apparently setting the
FORTRAN variable does not invalidate the sstate cache entry for the
gcc-cross recipe (which it should, as it affects the build outputs).

Perhaps it’s using locked sstate which might be the reason

I didn't know the sstate could be locked -- how would one unlock it? Could you
point me toward some relevant docs?

After some cursory searching the only thing I've found is the 'locked-sigs.inc'
file. And indeed, Petalinux does ship with a locked-sigs.inc file which
includes a signature for gcc-cross-arm. But adding gcc-cross-arm to
SIGGEN_UNLOCKED_RECIPES doesn't seem to have any effect.