Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 616566 - sys-devel/clang-4.0.0 uses the wrong chost prefix for symlinks (CHOST != CHOST_arm)
Summary: sys-devel/clang-4.0.0 uses the wrong chost prefix for symlinks (CHOST != CHOS...
Status: CONFIRMED
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: Current packages (show other bugs)
Hardware: All Linux
: Normal normal (vote)
Assignee: LLVM support project
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2017-04-25 10:44 UTC by Luca Barbato
Modified: 2017-04-25 13:59 UTC (History)
5 users (show)

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


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Luca Barbato gentoo-dev 2017-04-25 10:44:31 UTC
emerge clang-4 on an arm chroot results in clang installed as `arm-unknown-linux-gnu-clang` while compiler-rt tries to look for clang as "$CHOST"-clang failing to build.
Comment 1 Luca Barbato gentoo-dev 2017-04-25 10:45:20 UTC
You can experiment with it on my odroid, you should have vpn access to it already :)
Comment 2 Michał Górny archtester Gentoo Infrastructure gentoo-dev Security 2017-04-25 13:33:45 UTC
(amd64@ + toolchain@ as maintainer of multilib.eclass)
Comment 3 Michał Górny archtester Gentoo Infrastructure gentoo-dev Security 2017-04-25 13:59:47 UTC
Ok, so for completeness, i'll repeat what I said on IRC.

The symlinks are created for all ABIs, putting the list from get_all_abis (multilib.eclass) into a loop and calling 'get_abi_CHOST ${ABI}'. Now, this is pretty much how all get_abi_* functions work.

They use FOO_${ABI} variable if it is defined, and fall back to plain FOO if it is not. This pretty much means that for completeness the profiles define CHOST_arm and CHOST. Since you override only the latter, get_abi_CHOST uses the former. Now, this kinda sucks.

I see a few possible ways forward here:

1. Add extra symlink for $CHOST outside the loop. This would probably the cleanest solution ebuild-side, accounting both for 'standard' CHOSTs as defined by the profiles and custom CHOST defined by the user. It also adds a symlink if get_all_abis function does not return anything (i.e. with a broken profile). However, it doesn't solve the generic problem that you have two different values of CHOST, and ebuilds might use them interchangeably (esp. if multilib comes into the picture).

2. Special-case DEFAULT_ABI in the ebuild. I don't like that since it's non-generic; I would consider this as a last resort.

3. Attempt to solve the issue generically at eclass level. However, I don't know how would we do that properly. Remember that e.g. CFLAGS_${ABI} serve different purpose (they are appended to CC/CXX, and contain -m* flags) than CFLAGS, so we can't really apply any generic rule for ABI-variants of variables. Additional additional per-variable behavior sounds like an easy way to confuse the hell out of everyone even more.

4. Expect users to set CHOST_${ABI} and CHOST to the same value. We might add a warning to the eclass when the values are mis-synced but I guess that means a fair bit of work.

5. Do not define CHOST_${DEFAULT_ABI} in profiles. I don't think we could reliably go with this since it would make some profiles really messy (whenever CHOST_* assignments are reused by profiles with different default ABIs).