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

Tue Nov 6 03:03:21 PST 2012

On 11/06/2012 01:52 AM, M.E. O'Neill wrote:
> 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.
  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.

> 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...?

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

>
>      M.E.O.
>
>
> _______________________________________________
> cfe-dev mailing list
> cfe-dev at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev

-- 
Marc J. Driftmeyer
Email :: mjd at reanimality.com <mailto:mjd at reanimality.com>
Web :: http://www.reanimality.com
Cell :: (509) 435-5212
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20121106/a52290fd/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: mjd.vcf
Type: text/x-vcard
Size: 317 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20121106/a52290fd/attachment.vcf>