Created attachment 736780 [details] emerge --info '=sys-fs/zfs-2.0.5::gentoo' On a musl box of mine, a rebuild for a new kernel had this zfs build failure: Making install in man make[1]: Entering directory '/var/tmp/portage/sys-fs/zfs-2.0.5/work/zfs-2.0.5/man' Making install in man1 make[2]: Entering directory '/var/tmp/portage/sys-fs/zfs-2.0.5/work/zfs-2.0.5/man/man1' make[3]: Entering directory '/var/tmp/portage/sys-fs/zfs-2.0.5/work/zfs-2.0.5/man/man1' make[3]: Nothing to be done for 'install-exec-am'. /bin/mkdir -p '/var/tmp/portage/sys-fs/zfs-2.0.5/image/usr/share/man/man1' /usr/lib/portage/python3.9/ebuild-helpers/xattr/install -c -m 644 'zhack.1' '/var/tmp/portage/sys-fs/zfs-2.0.5/image/usr/share/man/man1/x86_64-gentoo-linux-musl-zhack.1' /usr/lib/portage/python3.9/ebuild-helpers/xattr/install -c -m 644 'ztest.1' '/var/tmp/portage/sys-fs/zfs-2.0.5/image/usr/share/man/man1/x86_64-gentoo-linux-musl-ztest.1' /usr/lib/portage/python3.9/ebuild-helpers/xattr/install -c -m 644 'raidz_test.1' '/var/tmp/portage/sys-fs/zfs-2.0.5/image/usr/share/man/man1/x86_64-gentoo-linux-musl-raidz_test.1' /usr/lib/portage/python3.9/ebuild-helpers/xattr/install -c -m 644 'zvol_wait.1' '/var/tmp/portage/sys-fs/zfs-2.0.5/image/usr/share/man/man1/x86_64-gentoo-linux-musl-zvol_wait.1' /usr/lib/portage/python3.9/ebuild-helpers/xattr/install -c -m 644 'arcstat.1' '/var/tmp/portage/sys-fs/zfs-2.0.5/image/usr/share/man/man1/x86_64-gentoo-linux-musl-arcstat.1' make install-data-hook make[4]: Entering directory '/var/tmp/portage/sys-fs/zfs-2.0.5/work/zfs-2.0.5/man/man1' cd /var/tmp/portage/sys-fs/zfs-2.0.5/image/usr/share/man/man1; \ /bin/sed --in-place -e 's/^\.Os$/.Os Linux/' \ zhack.1 ztest.1 raidz_test.1 zvol_wait.1 arcstat.1 /bin/sed: can't read zhack.1: No such file or directory /bin/sed: can't read ztest.1: No such file or directory /bin/sed: can't read raidz_test.1: No such file or directory /bin/sed: can't read zvol_wait.1: No such file or directory /bin/sed: can't read arcstat.1: No such file or directory make[4]: *** [Makefile:840: install-data-hook] Error 2 make[4]: Leaving directory '/var/tmp/portage/sys-fs/zfs-2.0.5/work/zfs-2.0.5/man/man1' make[3]: *** [Makefile:771: install-data-am] Error 2 make[3]: Leaving directory '/var/tmp/portage/sys-fs/zfs-2.0.5/work/zfs-2.0.5/man/man1' make[2]: *** [Makefile:724: install-am] Error 2 make[2]: Leaving directory '/var/tmp/portage/sys-fs/zfs-2.0.5/work/zfs-2.0.5/man/man1' make[1]: *** [Makefile:664: install-recursive] Error 1 make[1]: Leaving directory '/var/tmp/portage/sys-fs/zfs-2.0.5/work/zfs-2.0.5/man' make: *** [Makefile:893: install-recursive] Error 1 * ERROR: sys-fs/zfs-2.0.5::gentoo failed (install phase): * emake failed * * If you need support, post the output of `emerge --info '=sys-fs/zfs-2.0.5::gentoo'`, * the complete build log and the output of `emerge -pqv '=sys-fs/zfs-2.0.5::gentoo'`. * The complete build log is located at '/var/tmp/portage/sys-fs/zfs-2.0.5/temp/build.log'. * The ebuild environment file is located at '/var/tmp/portage/sys-fs/zfs-2.0.5/temp/environment'. * Working directory: '/var/tmp/portage/sys-fs/zfs-2.0.5/work/zfs-2.0.5' * S: '/var/tmp/portage/sys-fs/zfs-2.0.5/work/zfs-2.0.5' It appears to be adding the CHOST to the man page filenames
Full build.log is generally worth including just to avoid us asking for it ;)
why do you have CTARGET set? it's the culprit. if you set CTARGET - autotools act a little bit differently and appends it to some paths. as a result of that - this hook fails: https://github.com/openzfs/zfs/commit/b0f3e8a6ebe10a9098c7a984ae14c6fc9b0e0d7a#diff-157d6890f983cdcd5238c1886e529156d2c53e56db57aaa3c864b4ab6de4d7a3 because it does not account for CTARGET, I guess. while it should be fixed, you also should not set CTARGET on native host, as it forces autotools into cross mode.
I've never touched a CTARGET variable, my make.conf only has a CHOST="x86_64-gentoo-linux-musl" which I think is the musl stage3 default(?).
Interesting: /etc $ sudo grep CTARGET -R * csh.env:setenv CTARGET 'x86_64-gentoo-linux-musl' env.d/04gcc-x86_64-gentoo-linux-musl:CTARGET="x86_64-gentoo-linux-musl" env.d/gcc/x86_64-gentoo-linux-musl-10.3.0:CTARGET="x86_64-gentoo-linux-musl" environment.d/10-gentoo-env.conf:CTARGET=x86_64-gentoo-linux-musl profile.env:export CTARGET='x86_64-gentoo-linux-musl'
on my rather fresh system I only have this: /etc # grep -R CTARGET env.d/gcc/powerpc64le-unknown-linux-gnu-10.3.0:CTARGET="powerpc64le-unknown-linux-gnu" and no more mentions of it. on musl system: chr: ppc64_musl timberdoodle /etc # grep -R CTARGET env.d/gcc/powerpc64-gentoo-linux-musl-10.3.0:CTARGET="powerpc64-gentoo-linux-musl" but you also have env.d/04gcc-x86_64-gentoo-linux-musl which is propagated to environment. that's why CTARGET is set for you and you can see it in emerge --info output maybe a stray file from old times?
I do have env.d/04gcc-powerpc64le-unknown-linux-gnu file: # Autogenerated by 'gcc-config'. GCC_SPECS="" MANPATH="/usr/share/gcc-data/powerpc64le-unknown-linux-gnu/10.3.0/man" INFOPATH="/usr/share/gcc-data/powerpc64le-unknown-linux-gnu/10.3.0/info" you see, no mentions of CTARGET. so need to figure out why gcc-config decides to put CTARGET there for you.
I've seen upgraded gcc on the box affected and everything seems normal - I think this was a weird SELinux related bug. Closing for now.
