Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 782040 - catalyst calls get_libdir for lib64 but distcc installs under lib
Summary: catalyst calls get_libdir for lib64 but distcc installs under lib
Status: UNCONFIRMED
Alias: None
Product: Gentoo Hosted Projects
Classification: Unclassified
Component: Catalyst (show other bugs)
Hardware: AMD64 Linux
: Normal normal (vote)
Assignee: Gentoo Catalyst Developers
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2021-04-11 01:37 UTC by nic
Modified: 2021-04-17 05:45 UTC (History)
1 user (show)

See Also:
Package list:
Runtime testing required: ---


Attachments
distcc ebuild get_libdir multilib support (distcc-3.3.5.ebuild,5.31 KB, text/plain)
2021-04-11 16:21 UTC, nic
Details
distcc ebuild using /usr/libexec (distcc-3.3.5-r1.ebuild.txt,5.23 KB, text/plain)
2021-04-17 05:27 UTC, nic
Details
patch catalyst for distcc under libexec (catalyst-distcc-libexec-path.patch,1.31 KB, patch)
2021-04-17 05:29 UTC, nic
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description nic 2021-04-11 01:37:00 UTC
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
Comment 1 nic 2021-04-11 03:28:32 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
Comment 2 nic 2021-04-11 16:21:02 UTC
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
Comment 4 nic 2021-04-14 05:57:57 UTC
(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
Comment 5 Arfrever Frehtes Taifersar Arahesis 2021-04-14 09:46:50 UTC
$(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
Comment 6 nic 2021-04-17 05:27:34 UTC
Created attachment 700293 [details]
distcc ebuild using /usr/libexec
Comment 7 nic 2021-04-17 05:29:14 UTC
Created attachment 700296 [details, diff]
patch catalyst for distcc under libexec

against latest catalyst-9999
Comment 8 nic 2021-04-17 05:45:32 UTC
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