Created attachment 905139 [details] build.log I was cross-compiling some stuff for aarch64 and dev-perl/Net-SSLeay was in the dependencies. A gcc invocation failed: aarch64-unknown-linux-gnu-gcc -c -I"/usr/aarch64-unknown-linux-gnu/usr/include" -DOPENSSL_API_COMPAT=908 -DNET_SSLEAY_PERL_VERSION=5040000 -O2 -pipe -march=native -mtune=native -fomit-frame-pointer -fno-strict-aliasing -DNO_PERL_RAND_SEED -fwrapv -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -O2 -pipe -fomit-frame-pointer -mcpu=cortex-a53 -DVERSION=\"1.94\" -DXS_VERSION=\"1.94\" -fPIC "-I/usr/lib64/perl5/5.40/x86_64-linux/CORE" SSLeay.c Assembler messages: Error: unknown architecture `native' Looking at the flags it ran with, we see two sets of flags that looks like things I might have put in a make.conf: - from the host: `-O2 -pipe -march=native -mtune=native -fomit-frame-pointer` - from the target: `-O2 -pipe -fomit-frame-pointer -mcpu=cortex-a53` **I removed -march=native -mtune=native from my host make.conf and the error still persisted**, so it's not the host CFLAGS leaking in directly from my host make.conf. To find out more, I read the README for Net-SSLeay, and found this bit which seemed suspicious: > Please, do not send bug report before you have > > - compiled your OpenSSL yourself - don't copy binaries, please > - compiled your perl yourself and with substantially same CFLAGS > and same C compiler (say `which cc' or `which gcc') as your OpenSSL. > This is especially applicable to link errors and shared > library loading problems. Please do not even dream of > copying a perl binary or installing perl binary from a package. > Perl's idea of calling conventions has to match OpenSSL's and > unfortunately both are quite advanced pieces of code > (guru duel: Larry Wall vs. Eric Young :-) with dynamic loading > and who knows what > - compiled my module from source against correct perl (say `which perl' > and check your path). Generally my module's build process will > discover correct compiler and flags from `perl -V' > - tried gcc, if your vendor cc fails In particular, "Generally my module's build process will discover correct compiler and flags from `perl -V'" I check `perl -V | grep optimize` and indeed I see `-O2 -pipe -march=native -mtune=native -fomit-frame-pointer -fno-strict-aliasing`, which is a direct match for what's being used by SSLeay. So alright, let's **recompile my host perl** with different CFLAGS, and include something recognizable in there too $ CFLAGS="-O2 -pipe -fomit-frame-pointer -DARTEMIS_WAS_HERE=1" emerge -1 dev-lang/perl $ emerge-aarch64-unknown-linux-gnu -1 dev-perl/Net-SSLeay dev-perl/Net-SSLeay completes succesfully. Let's change its GCC invocation: aarch64-unknown-linux-gnu-gcc -c -I"/usr/aarch64-unknown-linux-gnu/usr/include" -DOPENSSL_API_COMPAT=908 -DNET_SSLEAY_PERL_VERSION=5040000 -O2 -pipe -fomit-fr ame-pointer -DARTEMIS_WAS_HERE=1 -fno-strict-aliasing -DNO_PERL_RAND_SEED -fwrapv -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -O2 -pipe -fomit-frame-pointer -mc pu=cortex-a53 -DVERSION=\"1.94\" -DXS_VERSION=\"1.94\" -fPIC "-I/usr/lib64/perl5/5.40/x86_64-linux/CORE" SSLeay.c rm -f blib/arch/auto/Net/SSLeay/SSLeay.so There it is, `-DARTEMIS_WAS_HERE=1`. Note **I never added this to my make.conf**, so the only possible way dev-perl/Net-SSLeay could be picking up this flag is by querying the host perl with `perl -V`. I cannot untangle this build system enough to figure out how `perl -V` is getting run or if there's a way to override it. The dev-perl/Net-SSLeay ebuild already sets `OPTIMIZE="${CFLAGS}"` in `mymake` before running `perl-module_src_compile`, so unfortunately that is not enough to convince this software to do the right thing.
Created attachment 905140 [details] pqv.txt
Created attachment 905141 [details] emerge-info
s/Let's change its GCC invocation/Let's check its GCC invocation/
