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

Michel Alexandre Salim salimma at
Sun May 13 05:21:53 UTC 2012

Hash: SHA1

On 05/11/2012 02:16 AM, Jon Masters wrote:
> On 05/10/2012 04:56 AM, David Airlie wrote:
>> Don't confuse llvm and clang, llvm has no equivalent in gcc
>> world, clang is a C compiler like gcc that uses llvm tech.
> Right so I wasn't confusing these :) However, we package both
> together and for ease of discussion many folks are going to think
> of it as a gcc alternative (aside from the specific gfx situations
> you and ajax have).
> My main concern was potential for growing use beyond that. I made
> an analogy about glibc to which I accept ajax's response that
> they're trying to reconcile with eglibc, but it's more the general
> concept I was getting at. Let me avoid a specific example because
> someone will find a way to find a hole in it :) Instead, my stance
> is we want to be very careful about unsupportable use of LLVM. I've
> filed a ticket with FESCo so hopefully there can be some debate as
> to acceptable use :)
>> It probably makes sense that one of myself, ajax or glisse help
>> out packaging llvm, but we aren't the most reliable people in
>> terms of spare time to commit.
> Right. You guys have various incentives to care about specific use
> of LLVM itself so I'm sure it will always be supported to some
> level, but for the other piece - clang+LLVM, etc. - to grow further
> use in the distro (in displacement of gcc) I feel we'd need to have
> actual RH staff to support it that I don't think we have any plans
> to have. So I want to cut this off at the pass before we blink and
> we have a problem.

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?

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.


- -- 
Michel Alexandre Salim
Fedora Project Contributor:

Email:  salimma at  | GPG key ID: A36A937A
Jabber: hircus at       | IRC: hircus at

()  ascii ribbon campaign - against html e-mail
/\   - against proprietary attachments
Version: GnuPG v1.4.12 (GNU/Linux)
Comment: Using GnuPG with Mozilla -


More information about the devel mailing list