[llvm-dev] [RFC] One or many git repositories?

Renato Golin via llvm-dev llvm-dev at lists.llvm.org
Thu Jul 28 07:30:21 PDT 2016

On 28 July 2016 at 09:42, David Chisnall <david.chisnall at cl.cam.ac.uk> wrote:
> I think it’s important to differentiate between ‘needs’ as in ‘requires a precisely matched version’ and ‘needs’ as in ‘requires something to provide this functionality’.  Clang needs something equivalent to libc++ and something equivalent to libunwind, but it doesn’t (or, at least, shouldn’t) need a specific version of LLVM’s implementations of these.  In contrast, clang needs a bunch of LLVM libraries and depends on precise versions.


> In FreeBSD, we used to ship libsupc++, libstdc++ and GCC’s libunwind.  We then switched to shipping libcxxrt, libstdc++, and GCC’s libunwind, then to shipping libcxxrt, libc++, and GCC’s libunwind, and are now switching to shipping libcxxrt, libc++, and LLVM’s libunwind.  We build all of these with clang and gcc.  When we import a new lldb and clang (and, soon, when we start to import lld), we need to do a complete import of LLVM, clang, lld, and lldb at the same time, or things will break.  We can update libunwind and libc++ on a different schedule.  We’ll probably want to keep roughly the same versions of these for an entire major release series (modulo bug fixes) for stability and we will want a new clang, lld, and lldb to work with the old ones.

My problem, and I'll be quick not to digress too much, is that
--rtlib=compiler-rt is slightly broken. I can't assume libunwind or
libc++abi are there, so for rtlib=RT, I don't add -lunwind and
-lc++abi "as needed" like we do for libgcc's counterparts.

This breaks expectations more than implementations. To use compiler-rt
I need to also add -lgcc_s or -lunwind, and that's not obvious. A
warning here would be weird.

Again, I totally agree it's not a hard requirement, nor version locked
or anything, but it would be good to "assume" the'd be there for the
*default* case, and let people mix and match by using other advanced


More information about the llvm-dev mailing list