Summary: | catalyst calls get_libdir for lib64 but distcc installs under lib | ||
---|---|---|---|
Product: | Gentoo Hosted Projects | Reporter: | nic <nic> |
Component: | Catalyst | Assignee: | Gentoo Catalyst Developers <catalyst> |
Status: | UNCONFIRMED --- | ||
Severity: | normal | CC: | nic |
Priority: | Normal | ||
Version: | unspecified | ||
Hardware: | AMD64 | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Attachments: |
distcc ebuild get_libdir multilib support
distcc ebuild using /usr/libexec patch catalyst for distcc under libexec |
Description
nic
2021-04-11 01:37:00 UTC
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 |