we currently flag ldconfig that is run during glibc's make install as violating the sandbox. this is because when we build as root, `ldconfig -r $D` will first do chroot($D), then access /etc/... from inside that. however, sandbox misses the chroot() call, thus it thinks that /etc/... access is the real /etc/... and not actually $D/etc/... and throws up a violation.
*** Bug 588418 has been marked as a duplicate of this bug. ***
As my bug report got marked as duplicate I ask the question here: "USE=vanilla builds -> your problem" Could you please be more specific? "My problem" reads like I have misconfigured something. Or is "my problem" a bug in sys-apps/sandbox? And how can it build (as you say) if this bug exists? Do you know how I could fix this? I really want to get this fixed as I have severe issues with glibc not giving back memory to the kernel for some applications I use. E.g. tmux collects up to all available memory (I already use a patch to fix this, but there are other applications I can't easily patch). In order to trace things down I wanted to start with glibc[vanilla].
(In reply to Franz Fellner from comment #2) this bug isn't about glibc or questions about its build/USE flags
The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/proj/genkernel.git/commit/?id=3e9ffa310cfcbadbe5c17160e72f0ff86feed8e4 commit 3e9ffa310cfcbadbe5c17160e72f0ff86feed8e4 Author: Thomas Deutschmann <whissi@gentoo.org> AuthorDate: 2019-08-11 19:42:14 +0000 Commit: Thomas Deutschmann <whissi@gentoo.org> CommitDate: 2019-08-11 19:48:58 +0000 gen_initramfs.sh: create_initramfs(): Disable sandbox for ldconfig ldconfig will use chroot(). However, sandbox doesn't understand that and believes we are writing to /etc/ld.so.cache... which is wrong. Bug: https://bugs.gentoo.org/431038 Signed-off-by: Thomas Deutschmann <whissi@gentoo.org> gen_initramfs.sh | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-)
Currently (sys-kernel/genkernel-4.0.5::gentoo) I get the following: * >> Pre-generating initramfs' /etc/ld.so.cache ... * Failed to pre-generate '/var/tmp/genkernel/gk_cLg8jJSd/initramfs-final/etc/ld.so.cache'! Probably due to sandbox/permission problem; Ignoring ... So ldconfig doesn't (re)create that ld.so.cache here, but there was already an existing ld.so.cache there of 103406 bytes, but after fixing this, the new ls.so.cache file is 352 bytes :) the fix is in /usr/share/genkernel/gen_initramfs.sh cat >"${TDIR}"/etc/ld.so.conf <<-EOF # ld.so.conf generated by genkernel include ld.so.conf.d/*.conf /lib /usr/lib EOF just replace that " include ld.so.conf.d/*.conf" with include /etc/ld.so.conf.d/*.conf Other things that have relative include path, but possibly irrelevant to anything(since nothing else, presumably, is running ldconfig -r): $ grep -nrI ld.so.conf.d.*00glibc eclass/toolchain-glibc.eclass:1358: echo 'LDPATH="include ld.so.conf.d/*.conf"' > "${T}"/00glibc sys-libs/glibc/glibc-2.19-r2.ebuild:1187: echo 'LDPATH="include ld.so.conf.d/*.conf"' > "${T}"/00glibc sys-libs/glibc/glibc-2.27-r6.ebuild:1291: echo 'LDPATH="include ld.so.conf.d/*.conf"' > "${T}"/00glibc sys-libs/glibc/glibc-2.28-r6.ebuild:1288: echo 'LDPATH="include ld.so.conf.d/*.conf"' > "${T}"/00glibc sys-libs/glibc/glibc-2.29-r2.ebuild:1330: echo 'LDPATH="include ld.so.conf.d/*.conf"' > "${T}"/00glibc sys-libs/glibc/glibc-2.30-r4.ebuild:1359: echo 'LDPATH="include ld.so.conf.d/*.conf"' > "${T}"/00glibc sys-libs/glibc/glibc-2.30-r5.ebuild:1359: echo 'LDPATH="include ld.so.conf.d/*.conf"' > "${T}"/00glibc sys-libs/glibc/glibc-2.26-r7.ebuild:770: echo 'LDPATH="include ld.so.conf.d/*.conf"' > "${T}"/00glibc sys-libs/glibc/glibc-2.29-r7.ebuild:1352: echo 'LDPATH="include ld.so.conf.d/*.conf"' > "${T}"/00glibc sys-libs/glibc/glibc-2.31-r1.ebuild:1371: echo 'LDPATH="include ld.so.conf.d/*.conf"' > "${T}"/00glibc sys-libs/glibc/glibc-9999.ebuild:1370: echo 'LDPATH="include ld.so.conf.d/*.conf"' > "${T}"/00glibc
