Installing gfortran into native sysroot for libgfortran


Gregory Anders <greg@...>
 

Hello,

I'm trying to compile libgfortran for a Xilinx Zynq SoC, which uses the arm-xilinx-linux-gnueabi toolchain.
I have added

    FORTRAN:forcevariable = ",fortran"

to my local.conf, which causes libgfortran to be built, but it fails in the configure stage with an error that
it cannot find arm-xilinx-linux-gnueabi-gfortran. When I check the recipe-sysroot-native directory of
libgfortran I indeed see that gfortran is not there (but -gcc, -g++, etc. are).

Now I've been poking around the gcc recipe files trying to figure out why gfortran is
not being installed, but I am coming up empty. I'm hoping someone on list know how to do this.
How can I have gfortran installed into the native sysroot for libgfortran?

Thanks,

Greg


Khem Raj
 

On Wed, Jul 6, 2022 at 5:51 PM Gregory Anders <greg@...> wrote:

Hello,

I'm trying to compile libgfortran for a Xilinx Zynq SoC, which uses the arm-xilinx-linux-gnueabi toolchain.
I have added

FORTRAN:forcevariable = ",fortran"

to my local.conf, which causes libgfortran to be built, but it fails in the configure stage with an error that
it cannot find arm-xilinx-linux-gnueabi-gfortran. When I check the recipe-sysroot-native directory of
libgfortran I indeed see that gfortran is not there (but -gcc, -g++, etc. are).

Now I've been poking around the gcc recipe files trying to figure out why gfortran is
not being installed, but I am coming up empty. I'm hoping someone on list know how to do this.
How can I have gfortran installed into the native sysroot for libgfortran?
in your fortran app recipe you have to add DEPENDS = "libgfortran"


Thanks,

Greg


Gregory Anders <greg@...>
 

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.


Richard Purdie
 

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?

It does sound like there is a bug to fix somewhere in there.

Cheers,

Richard


Gregory Anders <greg@...>
 

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).


Khem Raj
 



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 





Philip Balister
 

On 7/8/22 09:12, Khem Raj wrote:
On Fri, Jul 8, 2022 at 2:25 AM Gregory Anders <greg@... <mailto: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
It is. It was great fun to find the path to disable it when I also had this issue :)

Philip


Gregory Anders <greg@...>
 

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.


Gregory Anders <greg@...>
 

On Friday, July 08, 2022 11:40 AM MDT, Philip Balister <philip@...> wrote:

On 7/8/22 09:12, Khem Raj wrote:


On Fri, Jul 8, 2022 at 2:25 AM Gregory Anders <greg@...
<mailto: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
It is. It was great fun to find the path to disable it when I also had
this issue :)

Philip
(Apologies for the double post to the list.)

Philip, would you mind sharing what you did to disable it?

Thanks,

Greg


Philip Balister
 

In my notes:

cat /dev/null > conf/locked-signs.inc

Philip

On 7/11/22 12:49, Gregory Anders wrote:
On Friday, July 08, 2022 11:40 AM MDT, Philip Balister <philip@...> wrote:

On 7/8/22 09:12, Khem Raj wrote:


On Fri, Jul 8, 2022 at 2:25 AM Gregory Anders <greg@...
<mailto: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
It is. It was great fun to find the path to disable it when I also had
this issue :)

Philip
(Apologies for the double post to the list.)
Philip, would you mind sharing what you did to disable it?
Thanks,
Greg


Gregory Anders <greg@...>
 

On Mon, 11 Jul 2022 17:46 +0200, Gregory Anders wrote:
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.
I think I've finally figured this out and just wanted to provide some
closure for posterity's sake.

My initial "solution" of clearing the SSTATE_MIRRORS variable was not
actually correct. It turns out I was not actually even clearing it
correctly, and when I "fixed" it to correctly clear the variable it
caused a build error.

The solution was, in fact, to add gcc-cross-arm to
SIGGEN_UNLOCKED_RECIPES. I simply added this line to my configuration:

SIGGEN_UNLOCKED_RECIPES += "gcc-cross-arm gcc-runtime libgcc"

In my last message, I said that this had no effect. I can only guess
that it appeared that way because some other part of the build was being
cached. After clearing everything in the build directory and
re-building, it seems to work as expected.

Thanks to everyone who offered help.

Greg