crossdev either supports a profile which is built completely using clang or gcc -- it does not support a hybrid approach of building the optional gcc or clang compiler. This is needed because of many packages insist on clang/llvm like firefox, chromium, spidermonkey, dev-libs/libclc, dev-util/spirv-llvm-translator etc... Therefore there must be switches to build an optional gcc/llvm/clang compiler which will not be the system compiler, but will be available for use for use for the likes of above packages; otherwise building these packages with crossdev fails with error <archspec>-clang does not exist. Reproducible: Always
I've been using -- for i in `find /usr/lib/llvm/ -mount -name 'x86_64-<build host CHOST>-linux-gnu-*'`; do ln -s `echo -n $i | grep -Po '[^/]+$'` `echo -n $i | grep -Po /.*/``echo -n $i | grep -Po '[^/]+$' | sed s/-<build host CHOST>-/-<TARGET chost>-/`; done On the build host and it works great. I don't remember any failing any clang/llvm ebuild because of compiler issues.
I mentioned in your other bug that I had been implementing proper profile support. As part of that, I tried to deal with Clang/LLVM even though it's not something I'm especially interested in. As you say, the existing experimental support is inflexible and geared towards a very specific use case. Trying to fix this has proven extremely difficult. It involves several more packages, which is a pain because because crossdev's plethora of command line options have already spiralled out of control. I'd like to kill a lot of them off, but at the same time, Sam and I have been wondering whether it's time for crossdev to evolve into something very different that's more tightly integrated with the package manager. I doubt I'll find the time though.
