When using distcc enabled catalyst to build spec files. distcc-3.3.3-r3 ebuild installs under /usr/lib/distcc/ catalyst-3.0.17 uses $(get_libdir) and expects to find distcc under /usr/lib64/distcc As a result, chroot-functions.sh fails to create the appropriate chost wrappers Reproducible: Always Actual Results: errors observed during catalyst execution: /tmp/chroot-functions.sh: line 113: cd: /usr/lib64/distcc/bin: No such file or directory chmod: cannot access '/usr/lib64/distcc/bin/x86_64-pc-linux-gnu-wrapper': No such file or directory Expected Results: Either Catalyst should be patched to look under /usr/lib/, or Distcc should be patched to install under /usr/lib64 instead. Then then these commands should be able to run cleanly. referenced chroot-functions.sh script section: # This sets up automatic cross-distcc-fu according to # https://wiki.gentoo.org/wiki/Distcc/Cross-Compiling CHOST=$(portageq envvar CHOST) LIBDIR=$(get_libdir) cd /usr/${LIBDIR}/distcc/bin rm cc gcc g++ c++ 2>/dev/null echo -e '#!/bin/bash\nexec /usr/'${LIBDIR}'/distcc/bin/'${CHOST}'-g${0:$[-2]} "$@"' > ${CHOST}-wrapper chmod a+x /usr/${LIBDIR}/distcc/bin/${CHOST}-wrapper for i in cc gcc g++ c++; do ln -s ${CHOST}-wrapper ${i}; done
Finding additional errors to lib64 vs lib elsewhere in the catalyst workflows. Could be others yet which I haven't noticed >>> Regenerating /tmp/stage1root/etc/ld.so.cache... ln: failed to create symbolic link '/usr/lib64/distcc/bin/cc': No such file or directory ln: failed to create symbolic link '/usr/lib64/distcc/bin/gcc': No such file or directory ln: failed to create symbolic link '/usr/lib64/distcc/bin/c++': No such file or directory ln: failed to create symbolic link '/usr/lib64/distcc/bin/g++': No such file or directory Thank you
Created attachment 699276 [details] distcc ebuild get_libdir multilib support I've confirmed these distcc ebuild changes will allow a distcc enabled catalyst chroot-functions to run cleanly when provisioning the wrappers. Uses ${get_libdir) instead of hard-coded lib paths, found that some minor dir path cleanups were needed when switching an existing distcc install to lib64. distcc-3.3.5.ebuild can also be found within my Oubliette overlay, some minor patch tweaks were needed. Hope this helps
/usr/lib/distcc is used intentionally: https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=8fd91bf5725b7dad4ae7f1f6ccc8fd8c81bc5239 https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=9a6b6ae2b6542b104fc5618f46c6d3636ac089ce
(In reply to Arfrever Frehtes Taifersar Arahesis from comment #3) > /usr/lib/distcc is used intentionally: Unless I'm mistaken, distcc fixed those hard-coded paths back in Jun 2018 Bug 651030 predates those changes And --libdir successfully configures appropriately on my systems when passing /usr/lib64/ (at least to the best of my understandings) https://github.com/distcc/distcc/commit/bb4d613c08eeb2678e6b1095b99b7f8e870115cb Or is there another intentional necessity for not using get_libdir ? I also discovered that the Catalyst team only just recently Feb 2021 changed to /usr/lib/ (in git, no release published with fixes). So depending on the direction, there is some coordination needed. https://gitweb.gentoo.org/proj/catalyst.git/commit/?id=42332a642def9a8d454246da68955172442e7aa5 Thank you
$(get_libdir) should be respected for libraries and plugins, but it is not necessary to use it for executables. My personal preference would be /usr/libexec instead of /usr/lib (in this case /usr/libexec/distcc instead of /usr/lib/distcc), but it does not matter much. Portage supports searching distcc, icecream and ccache in all historically found locations: https://gitweb.gentoo.org/proj/portage.git/commit/?id=a41c0f8b9081dad610e6e82ab57a5adce30789ae
Created attachment 700293 [details] distcc ebuild using /usr/libexec
Created attachment 700296 [details, diff] patch catalyst for distcc under libexec against latest catalyst-9999
Thanks for the clarifications. I'm really deferring to you and the devs as to how best to unravel these old distcc /usr/lib/ workarounds. Or if at all, because if one installed catalyst-9999 (and migrated their spec files;) the functions have already been modified to align with that /usr/lib workaround; resolving the original errors I reported, but probably not ideal? Recent attachments change catalyst.git and distcc.ebuild to use /usr/libexec, I am still testing your proposed changes, so far so good. Hope this helps. Thank you