Currently, people using Clang as a system compiler will have it break when LLVM/Clang upgrades are done. This occurs because the older Clang is not able to work with the newer LLVM and the newer LLVM is merged before the older Clang is built. We need some way to tell portage not to merge LLVM upgrades until after immediately dependent packages in the dependency graph have been built.
What about: 1) slot llvm or 2) install llvm and clang with one ebuild
Option 2 probably would be the best thing here. I am CCing voyageur so he can comment on this.
This isn't a PMS bug, nor a portage bug; this won't be fixed at those layers either since it's a problem of how you're packaging it (aka, slot it or put it into a single pkg). Just to be clear; to do what you're asking at the PM level requires the PM to somehow make pkgs build against an intermediate copy of it's dependencies, both from / and ${D}. It's not sane.
Indeed, to recap some things from our IRC chat: * clang was supposed to get a separate build system someday, but this never happened * the current system involves rebuilding parts of llvm * slotting is complicated/not indicated (from upstream buildsystem, or mesa dependencies) So llvm[clang] sounds the way to go indeed
I'm not sure how exactly clang uses llvm. If it's just through the shared library, then slotting it may indeed be a good idea (especially due to things like mesa or other reverse deps). If it needs something more (headers in runtime, executables) it's a no-go. The gold plugin (for LTO) is another problematic thing. I really don't like the idea of putting everything into a single, awfully big package with heavy feature switches due to USEflags. But I guess that's the most probable way if upstream doesn't plan on decoupling it finally.
It seems that portage 2.2's preserved-libs circumvents this problem entirely, so only Gentoo Linux is affected.
(In reply to comment #6) > It seems that portage 2.2's preserved-libs circumvents this problem > entirely, so only Gentoo Linux is affected. Er? preserved-libs is system-independent :P.
(In reply to comment #7) > (In reply to comment #6) > > It seems that portage 2.2's preserved-libs circumvents this problem > > entirely, so only Gentoo Linux is affected. > > Er? preserved-libs is system-independent :P. Portage 2.2 is masked on Gentoo Linux
I have committed a testing version of joined ebuild in ::mgorny. I'd appreciate some testing of it since I'm low on time and resources, and I haven't even tried building with USE=-clang. I'll be happy to commit it and backport the change to older version(s) as soon as I get some test confirmations and voyageur's approval.
Initially fixed in llvm-3.3-r1 and -9999 through putting both in the same ebuild. We may need a different fix in the future though.
Bad news is that with current build system state, we'll probably have to end up breaking this. I suspect that we will end up doing three step build: 1. llvm, 2. clang, 3. compiler-rt. After step (1), preserved-libs will take care of keeping clang alive. However, after step (2), clang will lack proper runtime. This will be enough to build compiler-rt in step (3) but it may break parallel builds of random stuff.
