bug#69394: cross-gcc-toolchain for riscv64 doesn't search crt1.o properly

[Thiago Jung Bauermann]

Hello Jean-Pierre,

Today I ran into the issue reported in this bug with a custom toolchain
package for aarch64-linux-gnu. I applied your patch from issue 68058 and
that solved the problem!

Thank you very much for your insights and proposed solutions. A couple
of comments below:

Jean-Pierre De Jesus Diaz via Bug reports for GNU Guix <bug-guix@gnu.org> 
writes:

> 2. The other solution is to use NATIVE-SEARCH-PATHS but when using
> mixed toolchains
> in a single environment all of the cross compilers will share this
> environment variable.
>
> For example:
>
> guix shell gcc-cross-avr-toolchain gcc-cross-i686-w64-mingw32-toolchain
>
> Would have the same CROSS_* environment variables and could mix things up.
>
> Ideally one should have per target cross variables, like, CROSS_AVR_*
> CROSS_I686_W64_MINGW32_*, but this is not done right now.
>
> Another option is to wrap every binary of the toolchain and set the
> CROSS_* variables
> so that they can find the C standard library includes and binaries
> without adding
> search paths to avoid collisions with other toolchains for the moment and 
> since
> profiles don't support cross-packages yet I think it is a fair trade-off.
>
> I think I could update https://issues.guix.gnu.org/68058 to use the
> latter method.

That would be awesome.

If I understand correctly what you wrote, as things stand today many
cross toolchains are unusable because of this problem (but not all? IIUC
bare-metal cross toolchains aren't affected because they don't use
crt*.o files, right?)

So even your patch as it is currently proposed in issue 68058 would be
an improvement over the status quo.

IMHO, supporting more than one cross toolchain installed in the same
profile would be interesting (I for one would find it useful to have
both aarch64-linux-gnu and arm-linux-gnueabihf cross toolchains
installed at the same time) but even if that is not possible yet,
supporting just one cross toolchain installed in a profile would be an
important improvement. :-)

All this to say: unless there are other downsides to the patch in 68058,
I think it should be committed.

--
Thiago