Like C++? Not afraid of quirky build systems? Seeking LLVM co-maintainers

Jon Masters jcm at
Sun May 13 05:33:46 UTC 2012

On 05/13/2012 01:21 AM, Michel Alexandre Salim wrote:


> Maybe we should draw more of a distinction between LLVM and clang, and
> use ExclusiveArch: on the latter to whitelist only architectures we
> feel comfortable supporting?

We could. Right now, for ARM (as an example), there is really about as
much representation as x86 from what I can see in terms of core arch
support. I'm sure upstream bits will be pulled in, and David and ajax
will do a great job - but unless I'm mistaken they're not offering to
take on the task of being a architectural maintainer for core x86 code.
On x86, we have Jeff's tools group within Red Hat that does an excellent
job of providing all of the kinds of behind-the-scenes support that an
architecture really needs. It's not just fixing build issues, or whether
stuff builds on ARM - it's known how and why specific instructions are
emitted and how that relates to the design. IOW it's a full time job to
support something like clang at the same level that we support gcc today
and I don't see that level available.

Therefore, if ExclusiveArch is a solution, it ought to be ExclusiveArch:
none. Instead, while I think some arches do need to be considered for
exclusion - for example, if you compare the build flags for gcc and
llvm+clang today for non-ARM and non-x86 you'll see various stuff on
ppc/s390x that (to me) raises some concerns just in terms of the build
itself - I think more this should be "ExclusivePackage". I believe one
should have to make a case for growing a dependence like this within the
distribution. So we need it for soft rendering? Great. That's a
wonderful exception to a general rule of not requiring it. I don't mean
to sound anal, but we need to stop any growing in dependence on this
until we're in a position to broadly support on any arches.

(it's rather like how we have core packages depending on nonsense like
ruby or python in the SPEC file just to do something that a shell escape
could trivially have done ten years ago - if we don't make rules to stop
this growth there, we're making it much harder to bootstrap - therefore
rules do matter and we need them in this case before we start growing a
dependence on something as core as a new toolchain)

> I'm at the moment not really comfortable switching LLVM to be built
> with Clang as the default -- given that on Linux it has a brittle
> dependency on specific versions of libstdc++. But we could certainly
> make it a switchable build-time option.
> Apart from the worrying test suite results on secondary archs,
> actually it's the libstdc++ issue that's causing the most headache.
> How much effort does it take to maintain a compatibility version of
> libstdc++? It'd make clang much more useful if we're not caught
> between upstream (that abandons released versions) and the Fedora GCC
> team's fast update cycles.

I think upstream also not providing "support" is another red flag to be
honest. On the secondary arch front btw, I believe we have two problems
on ARM: one is some tests are failing (not unique to ARM), and two I
believe I am onto a heretofore not-well-isolated general futex bug that
isn't related to LLVM/clang as a package. Anyway, I don't feel in a good
position to comment on the libstdc++ resolution other than to again
repeat my concerns about having any growth in dependency.

Obviously don't take this personally! You do a great job Michel :) But
it's become clear to me that supporting a toolchain in Fedora requires a
team of folks to back it up that we don't seem to have here.


More information about the devel mailing list