It appears app-arch/xz-utils-5.0.4-r1 builds only a static liblzma.a here. Reproducible: Always
Created attachment 334556 [details] build.log
Created attachment 334558 [details] emerge.info
Created attachment 334560 [details] ppc64-emerge.info NOTE: This is in a cross-compilation environment with CBUILD=x86_64 and CHOST=powerpc64.
Found the issue: checking whether the /mnt/ppc64/etc/crossdev/gcc -std=gnu99 linker (/mnt/ppc64/etc/crossdev/ld -m elf64ppc) supports shared libraries... no Is there a way for portage to force configure to abort in this case?
The bad linker (wrong value for LD) was my fault. Would be nice of portage could somehow make econf/autoconf/configure bail out early in this case, i.e. force shared or static linking.
that makes no sense. there are targets which don't support dynamic linking.
(In reply to comment #6) > that makes no sense. there are targets which don't support dynamic linking. But in the case of xz-utils, it obviously requires shared-object support. So IMO it would make sense...
(In reply to comment #7) no, it doesn't. it depends entirely on the target whether a shared lib is used.
(In reply to comment #8) > no, it doesn't. it depends entirely on the target whether a shared lib is > used. Apparently the app-arch/xz-utils-5.0.4-r1 ebuild calls gen_usr_ldscript, which needs a shared library?
(In reply to comment #9) for some targets, yes. but not all.