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.
You can experiment with it on my odroid, you should have vpn access to it already :)
(amd64@ + toolchain@ as maintainer of multilib.eclass)
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).
Is this still relevant?
