RepoMan scours the neighborhood... dependency.unknown 2 sys-devel/llvm/llvm-3.5.2.ebuild: DEPEND: <sys-libs/libcxx-3.5.2.9999 sys-devel/llvm/llvm-3.6.2.ebuild: DEPEND: <sys-libs/libcxx-3.6.2.9999 999 Note: use --include-dev (-d) to check dependencies for 'dev' profiles RepoMan sez: "You're only giving me a partial QA payment? I'll take it this time, but I'm not happy." Either llvm should not depend on older libcxx, those versions should be removed, or those versions should be restored.
(In reply to Austin English from comment #0) > RepoMan scours the neighborhood... > dependency.unknown 2 > sys-devel/llvm/llvm-3.5.2.ebuild: DEPEND: <sys-libs/libcxx-3.5.2.9999 > sys-devel/llvm/llvm-3.6.2.ebuild: DEPEND: <sys-libs/libcxx-3.6.2.9999 > 999 > > Note: use --include-dev (-d) to check dependencies for 'dev' profiles > > RepoMan sez: "You're only giving me a partial QA payment? > I'll take it this time, but I'm not happy." > > > Either llvm should not depend on older libcxx, those versions should be > removed, or those versions should be restored. I think llvm works better with a matching version of libcxx. Using llvm-3.5 with libcxx-3.8 could possibly lead to compatibility issues. I don't know why older versions of libcxx were removed in the first place. Are llvm-3.5 and llvm-3.6 planned to be removed as well?
FWIW: llvm simply segfaults if you don't have the matching libcxx on certain platforms. It can't compile some stuff if it doesn't have the matching libcxx-headers (due to its own increased strictness, etc.)
Those versions are only for Prefix convenience, so reassigning.
these versions are no longer in the tree