The project has a set of variables defining build commands in Make.defaults that can be overridden, but there is no standard build system to handle cross-compilation.
Created attachment 476508 [details, diff] This defines all the configured cross-compiler programs The Makefile sets -flto which needs gcc-ar to succeed, but tc-getAR points at ar, hence the weird AR value.
The bug has been closed via the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=ab3ba62b708cd6829fbe939eef827b56ad9411bc commit ab3ba62b708cd6829fbe939eef827b56ad9411bc Author: David Michael <david.michael@coreos.com> AuthorDate: 2017-06-15 00:41:13 +0000 Commit: Virgil Dupras <vdupras@gentoo.org> CommitDate: 2018-09-29 01:01:48 +0000 app-crypt/pesign: Supply cross-compiling programs (with minor style changes from vdupras) Closes: https://bugs.gentoo.org/621804 Package-Manager: Portage-2.3.5, Repoman-2.3.2 Signed-off-by: Virgil Dupras <vdupras@gentoo.org> app-crypt/pesign/pesign-0.112.ebuild | 12 +++++++++--- 1 file changed, 9 insertions(+), 3 deletions(-)
I'm going to revert ar change since it obviously fails for CC having any other value than 'gcc', in particular including gcc version.
Did this need to be reopened? I think the ar version in the stable binutils package can handle LTO objects on its own these days. Cross-compilation still seems to work.
Might be specific to vanilla-kernel{,-bin} too.
I cross-compiled pesign to a bunch of architectures (i686, x86_64, ppc, riscv, some arm variants), and did not encounter any issues.
