[cfe-dev] Ghettoization of libc++, libc++abi, compiler_rt and lldb

[M.E. O'Neill]

If you want to build the LLVM core, or Clang, there are great build instructions on the website, but as we go out to other parts of the system (e.g., libc++, libc++abi, and compiler_rt), parts that I'd argue you still really *need* to use Clang to its fullest, we end up in a ghetto of patchy platform support and incomplete information that severely limits the number of people using them.

For example, if you want to use the latest cool -fcatch-undefined-behavior functionality in Clang, you need compiler_rt, but the build instructions in the "Get it and get involved!" section of compiler-rt.llvm.org are wrong.  They just don't work (wrong directory paths, missing dependencies for cmake).  They also suggest that you need cmake, when in fact there is a "working" Makefile.   But if you make it that far, you discover that actually some of the code for -fcatch-undefined-behavior is defined to be Linux only, even though the author thinks it would "probably work" on other platforms. (It does, if you can figure out how to make the build system build it.)

Another example is libc++ and libc++abi.  If their respective webpages are to be believed, they only work on OS X.  Yet a quick perusal of the libc++ source reveals that it *is* intended to build on Linux (and likely builds on FreeBSD, too).  But while it can be done, there are all sorts of traps and gotchas for those trying to build on Linux (e.g., the whole choose-a-workable C++ ABI issue; e.g., by default std::uncaught_exception() calls abort() -- PR13669).  None of these aspects are documented in a clear way, leaving people to try to glean what they can from blog posts and inconclusive mailing list threads.

Sometimes I hear excuses like, "Oh, I don't have a Linux box to test on", but these seem weak at best.  Virtual Machines are easy to make.  And if a developer lacks the skills or motivation to make a VM, they could perhaps ask here for volunteers to help, thereby making a friend who can help them test on other platforms besides their own.

I keep thinking these things will change by themselves as the project matures, but they haven't yet, and at this point, I'm wondering what it's going to take.  Don't we *want* people to use libc++ on Linux? Don't we want interested people to play with -fcatch-undefined-behavior on their Macs?  Because as it stands now, these parts of the clang world are accessible only to a small group of cognoscenti.

LLDB gives us a glimpse of how these subprojects can do better; it has detailed build instructions for both Linux and OS X, but only if you drill down to a subpage, which some people might not bother to do because the main page for LLDB claims that the only platforms known to work are Darwin-derived ones.

It would be wonderful if we could work out a fix for this situation and implement it.  To my mind, the obvious solution would be to declare some set of platforms (e.g., OS X, iOS, x86 Linux, and FreeBSD) to be supported by the project, and make it so that all key subprojects support these platforms unless there is a compelling reason to do otherwise.

Thoughts anyone...?

    M.E.O.