Ghettoization of libc++, libc++abi, compiler_rt and lldb

Clang Frontend
1

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.

2

And yet the build instructions are indeed not for a system set up with cmake, but for the old automake system. Half the projects build cleanly with automake, the other half are more mature with cmake. The answer we get is pretty figure it out on your own and once you do submit it for review. What you list seems like a minimum and should be fully tested, top-to-bottom. It seems Apple and Google have vested interests in Darwin [OS X and iOS] and Linux, respectively, so these two platforms [even the generic x86_64 for Linux] should work for both cmake and the automake approaches. They both have billions invested in this being solid for both of their respective hardware kernels they have chosen in the embedded space, never mind Apple directly in the consumer desktop/laptop/workstation space with x86_64. FreeBSD has committed thoroughly with LLVM/Clang being the default on their trunk. Debian has FreeBSD in-tree for their entire repository, It stands to reason both FreeBSD and Debian Linux can get all the major projects to work with both cmake and automake. Argonne Labs [Hal Finkel], to Dave at CRAY and other in more specialized areas clearly make sure what major projects they use work intimately with their own aims. I thought the discussion on cmake vs. automake was settled business but it is clear that in order for LLVM/Clang and the power of LLDB/Compiler-RT/Libc++ [libc++abi]/ not to forget Dragonegg that all these projects would be well served with more than just bone generic examples of running cmake …/trunk/llvm; make or …/trunk/llvm/configure; make while leaving all the real power on how to fine tune your builds up to hunting down reading through thousands of mail postings and filtering out the noise on how these optimizations apply best and in which domains. Documentation on building all the projects and how to fine tune them seems to be an obvious launchpad for engineers who get paid well in the first place to see this project a success, not to mention third party app developers won’t waste everyone’s time asking the same question over and over again if a solid and current FAQ with detailed examples were publicly available. For instance, The pros/cons of going shared-libraries versus static and what reason Debian Linux has for producing one monolithic shared-library when one goes to compile say OpenShading Language from trunk only having to find out by trial and error the necessary .so files to include in Larry’s cmake LLVM_LIBRARY variable when testing against LLVM/Clang trunk and how to best automate Deb build files from trunk for /usr/local install or /opt deb installs without disrupting /usr/lib/, /usr/bin for Debian’s own would be a nice reference back to Debian for instance. Reading through tens of thousands of mail posts with absolutely no archived categorization is another problem I don’t think any mailgroup has ever solved because there is no pre-defined tagging system in subject lines for people to work with as best to later allow for producing useful FAQ solutions. There is no NeXTAnswers and this place certainly could use one. Of course, I had to write some of those NeXTAnswers and the amount of perl script and hoops we had in-house at NeXT to produce them is a huge commitment. - Marc

3

All of the LLVM subprojects are extremely open to patches improving platform support. I'm sorry that you're running into problems getting various subprojects to work on your distribution; that's definitely not a state we want to be in. That said, expecting (say) Apple engineers to manually test deployment on every non-Apple platform is not really reasonable; that's just never going to be our priority. The right solution is to get it working and set up a buildbot to test that it stays working; at *that* point it's reasonable to expect that further commits won't break it. That initial work needs to come from someone who's actually familiar with the platform in question.

John.

4

There's a continuous integration testing service called Travis CI. It's for open source projects, it's free, easy to integrate and they host the tests.

They currently only supports Linux but they working on adding support for Mac OS X and Windows.