In pym/portage/package/ebuild/prepare_build_dirs.py, the ccache and distcc paths are hardcoded with 'lib', but for instance on a MIPS n32 system they're installed into /usr/lib32/.
How is portage supposed to know? Can it read the /usr/lib symlink to find out?
(In reply to comment #1) > How is portage supposed to know? Can it read the /usr/lib symlink to find out? MIPS has a weird set of ABIs, so the lib folder will actually contain o32 binaries, while lib32 will contain n32 binaries. So, there won't be a /lib or /usr/lib symlink. I'm not familiar with the portage code, but I'd think that portage should read the LIBDIR_${ABI} variable from the profile's make.defaults file. Isn't this how things like $(get_libdir) from the multilib eclass work? I haven't committed this change to the mips/mips64/n32 profile yet, but I've set it locally so that I can work out the bugs in building stages with the proper LIBDIR set.
(In reply to comment #2) > I haven't committed this change to the mips/mips64/n32 profile yet, but I've > set it locally so that I can work out the bugs in building stages with the > proper LIBDIR set. I've now committed this. Is what I suggested reasonable?
(In reply to comment #3) > Is what I suggested reasonable? I see your changes in profiles/arch/mips64 and guess that will work. However, at least for purposes of documenting the code changes in portage, it would be nice to have some explanation about why mips is different from the multilib profiles that set SYMLINK_LIB="yes" in profiles/features/multilib/make.defaults.
(In reply to comment #4) > I see your changes in profiles/arch/mips64 and guess that will work. However, > at least for purposes of documenting the code changes in portage, it would be > nice to have some explanation about why mips is different from the multilib > profiles that set SYMLINK_LIB="yes" in > profiles/features/multilib/make.defaults. Hm, I didn't know about this variable. Is this something I should set to "no" in MIPS' make.defaults?
The baselayout ebuilds all use a test like [[ ${SYMLINK_LIB} == "yes" ]], so if SYMLINK_LIB is unset in your profile then it should behave properly.
@toolchain: Do you recommend for portage to use the LIBDIR_${ABI} variable to locate /usr/$libdir/$tool/bin/ directories for ccache and distcc?
the issue is that ccache/distcc install into the *default* ABI libdir. for mips, and eventually for amd64, "lib" is not the default. so you'll want to read from ${LIBDIR_${DEFAULT_ABI}}, and default to "lib" if it isnt set.
Is there anything else you need, Zac? Some change to the mips profiles?
(In reply to comment #8) > the issue is that ccache/distcc install into the *default* ABI libdir. for > mips, and eventually for amd64, "lib" is not the default. so you'll want to > read from ${LIBDIR_${DEFAULT_ABI}}, and default to "lib" if it isnt set. Thanks, this is in git: http://git.overlays.gentoo.org/gitweb/?p=proj/portage.git;a=commit;h=dbc9f3cc4c665af6d5db24bd9fb7544ed711d96f (In reply to comment #9) > Is there anything else you need, Zac? Some change to the mips profiles? The profiles appear to have the required DEFAULT_ABI and LIBDIR_n32 variables set, so it looks good.
Great! Thank you :)
This is fixed in 2.1.10.1 and 2.2.0_alpha39.
Ah, looks like it's still hard coded (for distcc and ccache) in portage/pym/portage/package/ebuild/prepare_build_dirs.py
Ok, it's fixed in git now: http://git.overlays.gentoo.org/gitweb/?p=proj/portage.git;a=commit;h=e543f089e917e2d4029d3338238df4013d46c66a
This is in 2.2.0_alpha42, but I'll leave this bug open until it's in an unmasked release.
This is fixed in 2.1.10.4.