Created attachment 312637 [details] build log
Missing `emerge --info` and clicking the attachment is some binary rubbish (wrongly marked as text/plain?)
Right, it is bzipped, due to size limits, apologies.
[building initial core file in "output/cold-sbcl.core": writing 32768 bytes [1 page] from #<SB!FASL::GSPACE :READ-ONLY> writing 32768 bytes [1 page] from #<SB!FASL::GSPACE :STATIC> writing 46563328 bytes [1421 pages] from #<SB!FASL::GSPACE :DYNAMIC> /(DESCRIPTOR-BITS INITIAL-FUN)=#X1002AC974B done] * //testing for consistency of first and second GENESIS passes //header files match between first and second GENESIS -- good //entering make-target-2.sh //doing warm init - compilation phase make-target-2.sh: line 36: paxctl: command not found
what happens if you install paxctl in the chroot? ;)
(In reply to comment #4) > what happens if you install paxctl in the chroot? ;) The only package providing the command is sys-apps/paxctl? So unconditionally add this depend even for non-hardened users? Seems odd.
(In reply to comment #5) > The only package providing the command is sys-apps/paxctl? So > unconditionally add this depend even for non-hardened users? Seems odd. Looks like the usual practice is to add it conditionally with USE="pax_kernel". The USE flag is enabled in the hardened profile.
This issue may come from the sed rule in the ebuild: # Hack to disable PaX on second GENESIS stage sed -i -e '/load/!s/^echo \/\/doing warm.*$/&\npaxctl -C \.\/src\/runtime\/sbcl\npaxctl -mprexs \.\/src\/runtime\/sbcl/' \ "${S}"/make-target-2.sh || die "Cannot disable PaX on second GENESIS runtime" Which unconditionnaly try to call paxctl. However, this sed rule is protected by a `if host-is-pax' conditionnal. Reading the eclass, this evaluates to true if the kernel is PaX enabled. So the fact you are in a hardened chroot or not does not affect this test. This the sed rules is applied, and the build fails as it cannot find paxctl. I see two options here, maybe there are others : - Either the build inside a non hardened chroot using a hardened kernel is not supported, due to how `host-is-pax' works (Is this eclass function broken somehow ?) - Replace the `if host-is-pax' with `if use pax_kernel' instead.
(In reply to comment #7) > due to how `host-is-pax' works (Is this eclass function broken somehow ?) Reading carefully this eclass documentation: # This is intended for use where the build process must be modified conditionally # depending on whether the host is PaX enabled or not. It is not intedened to # determine whether the final binaries need PaX markings. I remove my first previous option, the ebuild wrongly use host-is-pax.
(In reply to comment #8) > # This is intended for use where the build process must be modified > conditionally > # depending on whether the host is PaX enabled or not. It is not intedened > to > # determine whether the final binaries need PaX markings. > > I remove my first previous option, the ebuild wrongly use host-is-pax. i agree, from old memories i'm pretty sure sbcl wants to generate code at runtime in general and it just so happens that its build process tries that already at build time. so the USE flag is the right conditional here.
Changed from "host-is-pax" to "use pax_kernel" in the 1.0.55-r1 ebuild. Closing.
