This package fails to compile on a stable system. Attached relevant logs and emerge --info
Created attachment 691590 [details] emerge_info emerge --info
Created attachment 691593 [details] sys-process:numactl-2.0.12:20210315-133918.log build log
> config.status: executing depfiles commands > config.status: executing libtool commands > * abi_x86_64.amd64: running multilib-minimal_abi_src_compile > CDPATH="${ZSH_VERSION+.}:" && cd /tmp/portage/sys-process/numactl-2.0.12/work/numactl-2.0.12 && aclocal-1.15 -I m4 > /bin/sh: aclocal-1.15: command not found > make: *** [Makefile:755: /tmp/portage/sys-process/numactl-2.0.12/work/numactl-2.0.12/aclocal.m4] Error 127 > * ERROR: sys-process/numactl-2.0.12::gentoo failed (compile phase): > * emake failed > *
1) This is weird: checking for a BSD-compatible install... /usr/lib/portage/python3.8/ebuild-helpers/xattr/install -c checking whether build environment is sane... yes /bin/sh: /tmp/portage/sys-process/numactl-2.0.12/work/numactl-2.0.12-abi_x86_64.amd64/build-aux/missing: No such file or directory configure: WARNING: 'missing' script is too old or missing checking for a thread-safe mkdir -p... /bin/mkdir -p Maintainer mode has been triggered when it tries to run aclocal again (a specific version). We need to understand why. Is there anything weird in your environment? Was config.log helpful? 2) These settings are dangerous: CFLAGS="-O2 -march=x86-64 -g0 -fno-stack-protector -fno-stack-clash-protection -fstack-check=no -fno-stack-check" CXXFLAGS="-O2 -march=x86-64 -g0 -fno-stack-protector -fno-stack-clash-protection -fstack-check=no -fno-stack-check" I know you know they're dangerous, but not just from a security perspective: they're going to end up breaking things. A lot of packages expect stack protection now and this is like testing them to their limit as to whether we filter everywhere we should. I'm also unsure if binutils (and other critical but non-glibc packages) also filter to the extent required. This sort of thing usually ends up with odd breakages appearing all over the place.. I wonder if this is related to the git bug with jq?
(In reply to Sam James from comment #4) > 1) This is weird: > > checking for a BSD-compatible install... > /usr/lib/portage/python3.8/ebuild-helpers/xattr/install -c > checking whether build environment is sane... yes > /bin/sh: > /tmp/portage/sys-process/numactl-2.0.12/work/numactl-2.0.12-abi_x86_64.amd64/ > build-aux/missing: No such file or directory > configure: WARNING: 'missing' script is too old or missing > checking for a thread-safe mkdir -p... /bin/mkdir -p > > Maintainer mode has been triggered when it tries to run aclocal again (a > specific version). We need to understand why. Is there anything weird in > your environment? Was config.log helpful? > > 2) These settings are dangerous: > > CFLAGS="-O2 -march=x86-64 -g0 -fno-stack-protector > -fno-stack-clash-protection -fstack-check=no -fno-stack-check" > CXXFLAGS="-O2 -march=x86-64 -g0 -fno-stack-protector > -fno-stack-clash-protection -fstack-check=no -fno-stack-check" > > I know you know they're dangerous, but not just from a security perspective: > they're going to end up breaking things. A lot of packages expect stack > protection now and this is like testing them to their limit as to whether we > filter everywhere we should. > > I'm also unsure if binutils (and other critical but non-glibc packages) also > filter to the extent required. > > This sort of thing usually ends up with odd breakages appearing all over the > place.. I wonder if this is related to the git bug with jq? Hi Sam, thanks for giving an hand here. I don't agree with you. I consider stack-protection a 'plus' and the program must behave in the same way with and without SSP. If you are right and the SSP is mandatory for a program then we must ensure that there is no breakage with user cflags ( via filter-flags ). I made a bit of diff with numactl build of another machine and I have: (CDPATH="${ZSH_VERSION+.}:" && cd /var/tmp/portage/sys-process/numactl-2.0.12/work/numactl-2.0.12 && /bin/sh '/var/tmp/portage/sys-process/numactl-2.0.12/work/numactl-2.0.12-abi_x86_64.amd64/build-aux/missing' autoheader) So do you have an idea because here it is doing: CDPATH="${ZSH_VERSION+.}:" && cd /tmp/portage/sys-process/numactl-2.0.12/work/numactl-2.0.12 && aclocal-1.15 -I m4 ?
Libtool was also broken so I started 'emerge -e world' to see if something will improve. Well it works now, I don't know what exactly was broken but it has not been catched by our tools.
