Summary: | LLVM and clang have to be lock step upgraded | ||
---|---|---|---|
Product: | Portage Development | Reporter: | Richard Yao (RETIRED) <ryao> |
Component: | Enhancement/Feature Requests | Assignee: | Richard Yao (RETIRED) <ryao> |
Status: | RESOLVED FIXED | ||
Severity: | enhancement | CC: | djc, grobian, mgorny, my, voyageur |
Priority: | Normal | Keywords: | Goal |
Version: | unspecified | ||
Hardware: | All | ||
OS: | All | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Bug Depends on: | 477432 | ||
Bug Blocks: | 408963 |
Description
Richard Yao (RETIRED)
2012-05-24 07:06:20 UTC
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. |