1. Computers
  2. Display Drivers
  3. Graphics Cards
  4. Memory
  5. Motherboards
  6. Processors
  7. Software
  8. Storage
  9. Operating Systems

Facebook RSS Twitter Twitter Google Plus

Phoronix Test Suite


Fedora To Remain Monogamist Towards GCC


Published on 15 May 2012 02:32 AM EDT
Written by Michael Larabel in Fedora

While FreeBSD 10 is preparing to fully switch to LLVM's Clang compiler and deprecate GCC, don't expect such a compiler change to happen in the Fedora camp in the foreseeable future. Fedora engineers have issued a statement reaffirming their commitment to GCC and stance on "alternative compilers" within this Red Hat distribution.

At the Fedora Engineering & Steering Committee (FESCo) meeting on Monday, the team members decided the growing use of LLVM and some projects not being concerned about GCC anymore. The statement that the FESCo members ended up agreeing to was "Packages may only build with an alternative compiler to gcc if upstream does not support gcc."

So only if the upstream package can't build with GCC -- due to using Clang-specific extensions or otherwise -- is that Fedora package permitted to being built with something other than GCC. Due to GCC being the de facto compiler for GNU/Linux, Red Hat being a large stakeholder in GCC, and most software building/working just fine with GCC, Fedora will remain monogamist towards GCC and then just "cheat" when needed to build other packages with LLVM/Clang or a different compiler.

Below is the relevant part of the IRC logs from yesterday's FESCo meeting.
17:04:03 [sgallagh] #topic #847 Request to have guidance on growing use of LLVM
17:04:04 [sgallagh] .fesco 847
17:04:06 [zodbot] sgallagh: #847 (Request to have guidance on growing use of LLVM) – FESCo - https://fedorahosted.org/fesco/ticket/847
17:04:55 [sgallagh] So my understanding is that some packages have decided to start using an alternate toolchain from gcc, and the concern is for supportability?
17:05:00 [nirik] I think if we get a growing number of things using llvm, we will also grow our ability to fix it.
17:05:07 [pjones] I think we should advise people to use llvm only where it's appropriate.
17:05:16 [limburgher] pjones: or required?
17:05:24 [pjones] limburgher: if it's required, it's appropriate.
17:05:26 [nirik] sgallagh: yeah.
17:05:28 [sgallagh] My I assume LLVM produces ELF binaries?
17:05:30 [t8m] I think llvm should be used only when it is really required.
17:05:32 [pjones] sgallagh: yes
17:05:36 [notting] nirik: i don't follow that line of reasoning. the number of apps that use filesystem features is not commensurate to the number of people competent to fix the VFS
17:05:42 [pjones] sgallagh: though it doesn't /have/ to, but sure.
17:05:48 [limburgher] t8m: That smells like a nascent policy. :)
17:06:08 [nirik] well, if people start using it and it breaks, they would either stop using it, or find a way to fix it, no?
17:06:18 [sgallagh] pjones: The real question I guess is whether a shared library built with LLVM will work with an app compiled in GCC and vice-versa
17:06:21 [mitr] nirik: LLVM is fairly easy to change... if you want to do small changes. Real features still require non-trivial expertise.
17:06:26 [nirik] not push that out to 'we can't ship foo because llvm doesn't work right'
17:06:40 [pjones] sgallagh: and if it doesn't, it's broken and people will file bugs and we'll have another discussion?
17:06:41 [notting] also, 'usage of LLVM' is vague. two separate areas of use: 1) using LLVM libs as a linked compiler for things (llvmpipe) 2) using clang as a system-level compiler
17:06:41 [mitr] sgallagh: There is an ABI, at least for C
17:06:43 [mjg59] I'm a big fan of having one way to do things
17:06:52 [mjg59] And I think that for C, that should typically be gcc
17:07:07 [sgallagh] pjones: Yes, I'm just trying to establish a base level of knowledge before I make any judgements
17:07:10 [mjg59] But gcc doesn't support the full set of features that clang supports, and there are going to be some packages that benefit from that
17:07:29 [pjones] sgallagh: the answer is: yes, it is supposed to be using the same abi
17:07:38 [mmaslano] I guess the guidance should be: gcc compilation must work
17:07:44 [pjones] mjg59: to say nothing of llvmpipe?
17:07:49 [pjones] mmaslano: eh?
17:07:51 [notting] mjg59: how does hfsplus-tools 'benefit' from clang? i'm confused what the feature is here, other than 'was written to build with it'
17:08:02 [mitr] My concern is that we have toolchain-based features fairly frequently (security-relevant, e.g. ExecShield, relro, or plain optimization, e.g. better ELF hashing), and supporting two separate compilers makes introducing such features at least twice as hard.
17:08:05 [pjones] mmaslano: if you're not choosing to use gcc, why must gcc compilation work?
17:08:09 [mjg59] notting: gcc doesn't support blocks
17:08:31 [pjones] notting: it won't compile with gcc. there's not much hope.
17:08:32 [notting] does clang use the binutils linkers, etc?
17:08:33 [mitr] mmaslano: "must work" doesn't say which one will e used...
17:08:43 [notting] or gold, or ...?
17:09:15 [mmaslano] well I read in the ticket: While this represents a good technology advance, Fedora is heavily invested (in staffing, experience) with GCC.
17:09:56 [mitr] mmaslano: if a package is built with llvm, I can't see how it matters that it "can" build with gcc
17:10:11 [notting] proposal-that-is-way-too-technical: if your code *can* build with gcc, it *must* be built with gcc. if it can't, please consider working on porting it.
17:10:24 [t8m] notting, I like it
17:10:26 [mitr] notting: sounds like a good policy for today.
17:10:37 [pjones] notting: I'm honestly not convinced we're not better off avoiding the "you must use this tool" game.
17:10:54 [mmaslano] notting: yes, I was looking for something like that. Thanks
17:10:56 [sgallagh] jonmasters: Do you want to make any comments on this? You opened the request.
17:11:27 [mitr] Long-term, I suppose there are two concerns: 1) if we ever switched from gcc, how would that work? flag day in a single Fedora release?, and 2) what makes using gcc/llvm in parallel from using, say, gcc and ocaml in parallel?
17:11:34 [nirik] it seems to me stuff like this shakes out without a mandate from a govenering body, but perhaps I'm wrong.
17:11:35 [notting] so, for mjg59's hfsplus-tools example, it could be 'considered porting. not worth the effort at this time'.
17:11:48 [pjones] notting: there's a lot of stuff using cmake, which I don't happen to like much - why aren't we talking about banning cmake?
17:11:50 [sgallagh] notting: I could agree with that. As mentioned above, we have numerous security policies such as relro that we have in place for GCC
17:11:58 [t8m] mitr, for 2) you can hardly compile ocaml code with gcc :D
17:12:06 [mjg59] notting: It's not even infeasible to port it, but it would represent a (likely permanent) divergence from upstream
17:12:20 [mitr] t8m: same for current hfsplus - the two are not a subset/superset
17:12:43 [t8m] mitr, and I don't think we should deny hfsplus just because it doesn't compile with gcc
17:12:44 [mitr] mjg59: btw. how do blocks differ from gcc nested functions? Syntax only?
17:12:55 [pjones] nirik: I think you're right. furthermore, given the... lackluster feature support of gcc in terms of, for example, why didn't we have a llvmpipe-like-library a decade ago...
17:13:02 [pjones] nirik: frankly I'd like to encourage the competition.
17:13:04 [mitr] t8m: right, that's my concern.
17:13:11 [mjg59] mitr: Other than that, not hugely. Implementation-wise - gcc's nested functions require an executable stack.
17:13:16 [notting] pjones: i don't think llvmpipe-type-library-usage is even up for discussion, here?
17:13:20 [pjones] mjg59: and a lot of vomit
17:13:22 [t8m] mitr, in the nottings proposal there is no such thing
17:13:33 [notting] ok, let's restate:
17:13:52 [notting] - clang should only be used for packages which use clang-specific C extensions.
17:14:19 [t8m] notting, that's fine as well
17:14:25 [sgallagh] notting: +1
17:14:25 [pjones] notting: no, I was just saying that's an example where I think gcc needs more encouragement to do something useful. there are others, and I think we should be encouraging a healthy amount of competition between gcc and clang/llvmpipe/etc. instead of saying "don't use this it's bad because we don't understand it that well mmmkay?"
17:14:34 [notting] pjones: what i want to avoid is having to deal with divergent weirdness from upstreams for $random_package_X that decided to build with clang this release
17:14:55 [pjones] notting: I don't see how any policy we make will affect that
17:15:08 [mjg59] notting: I'm fine with that, but I think we should arguably go further and encourage standardisation on toolchain in other respects as well
17:15:09 [notting] or, god forbid, someone trying to run "alternatives --configure cc"
17:15:30 [notting] is salimma around?
17:15:31 [pjones] I can certainly be convinced to vote against clang as an alternatives option for gcc ;)
17:15:46 [pjones] That's not going to take a lot of convincing, even.
17:15:49 [mitr] mjg59: I have difficulty asking for that with straight face, considering that the old Fedora Core packaging merge reviews still aren't all done...
17:16:04 [mjg59] Anyway, can we punt this off to packaging?
17:16:13 [mjg59] It sounds like a perfectly reasonable packaging guideline
17:16:15 [notting] currently there are two packages that build with clang
17:16:15 [nirik] it's not a guideline, it's policy
17:16:20 [t8m] nirik, +1
17:16:38 [notting] it's a policy that would land in the packaging guidelines
17:16:39 [mjg59] nirik: If it's a policy of "should" then it's a guideline :p
17:16:55 [mitr] packaging guidelines are policies... but whatever
17:17:18 [nirik] proposal: FESCo suggests that packages using clang/llvm carefully consider such use against standard toolchain use. No other guideance at this time. Revisit if there's an issue?
17:17:22 [t8m] I think that FESCo should decide on the base direction and FPC can fine tune it
17:17:32 [notting] nirik: -1, i'd prefer something stronger
17:17:37 [t8m] nirik, -1
17:17:41 [limburgher] t8m, notting +1
17:17:58 [nirik] ok. counter proposal? :)
17:18:01 [mjg59] I'm fine with notting's proposal
17:18:10 [sgallagh] nirik: -1, I'm still in favor of notting's proposal
17:18:13 [t8m] I'm fine with either of notting's proposal
17:18:20 * nirik reads back up for nottings proposal
17:18:25 [notting] proposal: Packages may only build with clang if they use clang-specific language extensions.
17:18:32 [mmaslano] I like notting's proposal
17:18:45 [mmaslano] +1
17:18:48 [drago01] why is this specific to clang
17:18:49 [pjones] I don't particularly like either of notting's proposals. I don't think we need to ban clang, even in such a weak way.
17:18:49 [sgallagh] +1
17:18:51 [t8m] +1
17:18:54 [nirik] but then anyone could add such? I suppose it stops people from switching for no reason
17:18:54 [drago01] what about $otherccompiler ?
17:18:55 [limburgher] +1
17:18:57 [notting] proposal-addition-that-I-would-hope-I-wouldn't-need-to-specify: don't add clang-specific usage in patches ;)
17:19:02 [pjones] drago01: it isn't, that's just the only other real option
17:19:22 [limburgher] nirik: If they care enough to switch, they probably want something it has that gcc doesn't.
17:19:34 [mitr] limburgher: clang's diagnostics, perhaps?
17:19:47 [drago01] pjones: no idea open64? my point was just "make this generic"
17:19:47 [sgallagh] notting: Perhaps: "Packages may only build with an alternative compiler to gcc if upstream requires compiler-specific language extensions"
17:20:02 [pjones] limburgher: which is why I think we should be encouraging them
17:20:04 [notting] sgallagh: i'll take that. +1
17:20:05 [limburgher] mitr: Maybe.
17:20:10 [mjg59] Can we also define a standard lisp implementation?
17:20:13 [pjones] drago01: meh. I don't think it matters, practically.
17:20:30 [mitr] +1 - I don't particularly like the banning of clang as a general policy, but given that there is 0 push to make clang the default, I think it is fine for the current 1-2? years
17:20:31 * nirik is with pjones here.
17:20:36 [pjones] mjg59: now you're arguing against something you've said you're okay with?
17:20:47 [limburgher] pjones: I think this clarifies things, and helps people move forward.
17:20:54 [pjones] limburgher: I don't see how?
17:20:55 [nirik] anyhow, I think there's enough votes to pass notting's proposal?
17:21:07 [notting] nirik: i prefer sgallagh's wording, tbh
17:21:11 [nirik] or we could vote on sgallagh's
17:21:12 [mjg59] pjones: I think there's value in consistency here
17:21:13 [pjones] what does it clarify? for whom? Who has been struggling on moving forward because they couldn't figure out if they should use gcc or not?
17:21:17 [t8m] +1 for the sgallagh's proposal as well
17:21:30 [mjg59] pjones: If we're defining a standard C toolchain we should do the same for other languages that have multiple options
17:21:31 [pjones] mjg59: oh, you're *genuinely* saying we should pick a standard lisp?
17:21:35 [sgallagh] #proposal "Packages may only build with an alternative compiler to gcc if upstream requires compiler-specific language extensions"
17:21:44 [mjg59] pjones: If possible, sure
17:21:48 [t8m] sgallagh, +1
17:21:54 [sgallagh] mjg59: Open a ticket for next week, please
17:22:27 [pjones] sgallagh: can we not rush to vote on this while we're still discussing it?
17:22:29 [notting] pjones: so, you're saying that this proposal is solving a non-problem?
17:22:31 [mitr] mjg59: That will run into the same problem - different implementations do not have a feature subset/superset relationship - and in a worse way than clang/gcc
17:22:38 [mjg59] mitr: Right
17:22:39 [pjones] notting: I'm saying it's making an existing problem worse
17:22:51 [mjg59] mitr: I just don't think there's a fundamental difference between C and any other language
17:22:56 [limburgher] pjones: No idea. But now instead of wondering, walking into a minefield, they at least know what we think currently.
17:23:02 [t8m] pjones, how so?
17:23:04 [mjg59] And I don't think solving this argument purely for C is very helpful
17:23:17 [pjones] the existing problem being that gcc is unfortunately academic and often fails to provide a more useful tool, and clang is showing them how to do it better. if we discourage clang, we discourage gcc improving as well.
17:23:55 [notting] i think attempting to redirect gcc development via our packaging policies is not the most direct of a lever
17:23:55 [drago01] mjg59: yeah that makes sense to me
17:23:58 [mitr] mjg59: Right, I see that - OTOH there are "soft" differences": in practice C is a dominant language that makes it more important, and has a dominant implementation (and we do take advantage of the dominancy of said implementation)
17:24:11 [t8m] maybe we could allow also using clang where upstream is encouraging it as well?
17:24:13 [pjones] notting: so we're trying to influence *every* upstream instead of just the one?
17:24:23 [t8m] s/clang/alternative compiler/
17:24:47 [mitr] t8m: That runs straight into the "new features in toolchain" problem
17:24:49 [mjg59] Ok, so obvious straw-man argument:
17:24:55 [drago01] "use the compiler prefered by upstream"
17:25:10 [pjones] drago01: and that, I could get behind.
17:25:11 [nirik] drago01: +1
17:25:13 [mjg59] Red Hat has much more engineering support for Gnome than for KDE. We should change the packaging guidelines to request that everyone consider porting their applications to GTK.
17:25:15 [t8m] I'd just like to prevent switching random packages to clang just because the pkg maintainer likes it.
17:25:29 [pjones] mjg59: you know how I feel about that :)
17:25:48 [mitr] pjones: OTOH, I've been doing some work with LLVM, and at least 2-3 years ago it was a toy compared to gcc in many respects. Sure, a toy that produced working code, but...
17:25:53 [pjones] t8m: and that's fair, but that's not what the earlier policy suggests - in fact it's much more modest
17:26:33 [mitr] So I'm not really fond of cheering on switching to clang right now - but I definitely don't want to close the door forever
17:26:34 [mjg59] I agree that (at least for now) we should encourage people to use gcc rather than clang where possible, but I also believe that about several other components
17:26:35 [notting] how is the policy of "only use if you don't have an alternative" more modest?
17:26:40 [pjones] mitr: sure - but if an upstream picked it, then we're trusting their code and implicitly saying we don't trust their makefile to run something sane to build it? and we're saying they didn't know what they were doing when they chose how to compile it?
17:26:50 [t8m] pjones, well I'd like to be a slightly more strict however I'd be fine even with this modest policy better than nothing
17:27:06 [mitr] pjones: clang may be "sane", but suppose it doesn't have FORTIFY_SOURCE - which one is more important?
17:27:24 [pjones] notting: that policy encourages people to use gcc instead of clang when upstream has chosen clang and merely not written something /incompatible/ with gcc. I think that's a bad plan.
17:27:27 [mitr] (Note: I haven't checked whether it supports that or not)
17:27:33 [notting] pjones: examples?
17:27:37 [pjones] mitr: fair point
17:28:09 [pjones] notting: admittedly, I have none - but that's partly because we're discussing this at a time when there are 2 packages in the distro that use clang. which is to say we're being rather aggressive about discussing it.
17:28:23 [mjg59] #proposal: Since making this decision involves deciding whether we want Fedora to be a platform or a software collection, ask the board first
17:29:05 [notting] my concern is much the same as mitr's - we use the compilation environment to set platform features (fortify source, relro, debuginfo generation, etc. etc. etc.). hence, we benefit for uniformity in all but the most extreme (i.e., won't work otherwise) cases
17:29:10 [mjg59] Rationale: Platforms have one implementation of each component
17:29:13 [mitr] mjg59: I can't see that we can be purely one or the other, ever
17:29:29 [notting] does clang even product compatibile debuginfo, for example?
17:29:31 * nirik doesn't think fedora will be a platform, but sure you could ask the board.
17:29:50 [pjones] notting: and I think that's a fair discussion, but I'm not sure we that means it's time to take action
17:30:14 [pjones] s/we //
17:30:15 [t8m] but policy can be always changed
17:30:27 [t8m] if it is not adequate any more
17:30:27 [pjones] t8m: yes, but it's harder to change a policy than make a new one
17:30:31 [notting] pjones: on the other hand, i think that it makes a fine policy to *not* do something unusual without a Really Good Reason
17:30:34 [sgallagh] Yes, the policy that's sensible today may be revised in a year
17:31:27 [t8m] I still think either notting's/sgallagh proposal or the 'follow upstream' proposal can get enough votes today
17:31:40 [mitr] notting: Well... how _do_ we currently support languages with non-gcc compilers? Are we fine with what we do there? Is there something that we can/need to improve in that respect, and could it be applied to clang as well? (Most likely, lack of manpower will kill any such push)
17:32:16 [sgallagh] mitr: In most cases (python, R, Java) we have a single implementation
17:32:24 [t8m] mitr, most non-C languages do not have buffer overflows
17:32:50 [t8m] so no need for things such as FORTIFY_SOURCE
17:32:50 [notting] sgallagh: techncially, we have 4 python runtimes, at least
17:32:52 [nirik] (well, python and java have multiple versions too, but thats not a big deal)
17:32:55 [mitr] t8m: I suppose...
17:33:05 [limburgher] nirik: Speak for yourself. :)
17:33:12 [notting] sgallagh: only two of them get used, and only one by the majority
17:33:37 [sgallagh] notting: Ok, I suppose I should have limited myself to compiled languages rather than interpreted.
17:33:40 [pjones] sgallagh: I'm not really seeing how the policy is sensible today. have we had some giant problem with the current state of affairs?
17:33:43 [notting] we're at ~30 m inutes? vote, continue discussion, or...?
17:33:49 [limburgher] And we have Guidelines around how to support both, but you have to support the default.
17:34:28 [limburgher] I'm ready to vote, but it seems like there's more discussion desired, and that's fine with me.
17:34:29 [sgallagh] I think we're fairly well polarized on the issue at this point.
17:34:29 * nirik also doesn't see the big problem today. If some maintainer switches a critpath package to use it, and it breaks, we ask them to change back? or get upstream to help fix clang, or ?
17:34:45 [notting] pjones: the example would be one large portion of the OS (yum? pygobject3? something else) wanting to move their stack to ABI-incompatible pypy
17:34:56 [mitr] pjones: our choices basically are 1) hope that clang won't gain traction, 2) give up on toolchain-based features for the future, 3) find enough qualified people to work on the llvm toolchain to maintain parity, 4) minimize use of clang.
17:35:04 [mjg59] If the concern people have is that clang doesn't necessarily support the full set of functionality that we expect from gcc, then we should probably check that before making a decision
17:35:05 [notting] pjones: you're saying we should not standardize against that now?
17:35:14 [t8m] mitr, +1
17:35:26 [pjones] notting: do we have some reason to believe that pypy would decide to make everything abi incompatible?
17:35:36 [notting] pjones: it *is* now
17:35:43 [pjones] oh, huh. well, okay :)
17:35:54 [mjg59] But I do see mitr's point
17:36:19 [notting] to mitr's point, i would rather do #4, and revisit later ,than #1 and deal with the fallout
17:36:21 [mjg59] It's a problem if we can't enable useful functionality across the distribution unless the people doing the work on one compiler don't also do it on the other
17:36:25 [nirik] if some big upstream switched to use it, how could we forbid it? carry gcc patches locally to the end of time? at some point we have to follow what the people who write our software do
17:36:55 [nirik] anyhow, we should vote or table for more info, IMHO
17:37:11 [mitr] nirik: extending gcc is also an option, at least in theory
17:37:12 [limburgher] Follow upstream seems logical, to a point.
17:37:31 [pjones] mjg59: so we can't use blocks or clang's diagnostic features until gcc implements them?
17:37:53 [pjones] (okay, argue against blocks, fine. diagnostic features? surely those are useful functionality?)
17:38:17 [sgallagh] pjones: Can you expound a bit on the diagnostic features?
17:38:24 [sgallagh] Are we just talking about its static analysis stuff?
17:38:29 [t8m] diagnostic features can be used with local builds not necessarily have to be used within the distro packages
17:38:31 [mjg59] clang is much better at producing useful errors
17:38:36 [mitr] sgallagh: e.g. http://clang.llvm.org/diagnostics.html
17:38:37 [sgallagh] Because individual projects can take advantage without doing so in the final packages
17:38:46 [t8m] yeah
17:38:59 [pjones] sgallagh: http://clang.llvm.org/diagnostics.html
17:40:14 [mitr] Proposal: Ask gcc and llvm maintainers for opinion about maintaining features in both at the same time, and revisit next week
17:40:22 [pjones] t8m: sgallagh: you can't be serious? now you want people to conditionalize their build on whether it's local or distro?
17:40:31 [t8m] pjones, why not??
17:40:37 [mitr] (I'm not sure that it will change anything - but we really didn't have expert input so far)
17:40:47 [nirik] everyone wants to test things twice. not.
17:40:49 [pjones] t8m: because it's a giant pain in the ass that's going to lead to even more bugs?
17:41:11 [notting] mitr: -1... i think we have enough information here to make a reasonable proposal judgement, and now we're just going in circles around the drain
17:41:37 [pjones] mitr: I don't really think that has any chance of getting anywhere?
17:41:42 * nirik also thinks we are circling. Perhaps a final proposal to vote on?
17:41:53 [sgallagh] pjones: I meant upstreams can build with clang if they want to run diagnostics, but RPM builds should always be GCC
17:42:07 [sgallagh] *where possible
17:42:24 [pjones] sgallagh: so then when there's a bug in one or the other, all of upstream's testing is invalid
17:43:08 [mitr] notting: How many people have llvm programming experience here? My experience is somewhat outdated already... but yeah, not looking forward to another 40 minutes next week.
17:43:14 [sgallagh] pjones: State your proposal, I will state mine, everyone can vote on the two.
17:43:17 [sgallagh] Is that reasonable?
17:43:23 [t8m] sgallagh, +1
17:43:26 [mmaslano] sgallagh: sounds fine
17:44:20 [sgallagh] #proposal Packages may only build with an alternative compiler to gcc if upstream does not support gcc
17:44:21 [pjones] sgallagh: my proposal is that this doesn't merit changing our policies at this time
17:44:31 [t8m] sgallagh, +1
17:44:35 * nirik is with pjones on this one.
17:44:37 [sgallagh] (I've made that slightly simpler than before, to allow upstream more leeway)
17:44:48 [t8m] pjones, -1
17:44:57 [mitr] sgallagh: "support" means "is able to build with", or "recommends"?
17:45:29 [mjg59] Eh. I think I'm starting to lean more towards pjones here.
17:45:34 [sgallagh] mitr: I suppose recommends is probably closer to what I meant.
17:45:56 [mitr] In that case I'm... not sure there is any difference between the two :)
17:46:02 [sgallagh] But with a stronger preference towards gcc if possible
17:46:34 [sgallagh] mitr: A recommendation is different from a mandate
17:46:42 [notting] +1 to sgallagh's proposal
17:46:43 [sgallagh] "We prefer clang but work with gcc" -] GCC
17:46:48 [notting] i'd prefer it be stronger
17:47:10 [limburgher] +1 sgallagh
17:47:12 [mitr] I'd prefer it to be a bit stronger, but can be +1 to sgallagh's proposal
17:47:18 [t8m] pjones, if $random maintainers start patching their packages to build with clang will we make the policy?
17:47:25 [mmaslano] +1 for sgallagh
17:47:32 [sgallagh] I'm willing to revise the text of it if you have better phrasing
17:47:53 [pjones] t8m: is there any evidence anybody is clamoring to do that?
17:48:03 [pjones] t8m: if that becomes a thing, I'm all for more discussion
17:48:18 [t8m] I see 6 votes for sgallagh's proposal.
17:48:40 [t8m] (if sgallagh votes for it)
17:48:46 [sgallagh] +1 ;-)
17:49:10 [sgallagh] Clearly not a consensus, but I think that's a decision at least
17:50:06 [nirik] indeed. shall we move on?
17:50:18 [mmaslano] please
17:50:27 [t8m] :)
17:50:30 [sgallagh] #agreed Packages may only build with an alternative compiler to gcc if upstream does not support gcc (6 +1)

About The Author
Michael Larabel is the principal author of Phoronix.com and founded the web-site in 2004 with a focus on enriching the Linux hardware experience and being the largest web-site devoted to Linux hardware reviews, particularly for products relevant to Linux gamers and enthusiasts but also commonly reviewing servers/workstations and embedded Linux devices. Michael has written more than 10,000 articles covering the state of Linux hardware support, Linux performance, graphics hardware drivers, and other topics. Michael is also the lead developer of the Phoronix Test Suite, Phoromatic, and OpenBenchmarking.org automated testing software. He can be followed via and or contacted via .
Latest Linux Hardware Reviews
  1. Intel Launches The Core i7 5960X, Mighty Powerful Haswell-E CPUs
  2. AMD Radeon R9 290: Gallium3D vs. Catalyst Drivers
  3. AMD Radeon R9 290 Open-Source Driver Works, But Has A Ways To Go
  4. Trying The Configurable 45 Watt TDP With AMD's A10-7800 / A6-7400K
Latest Linux Articles
  1. The Fastest NVIDIA GPUs For Open-Source Nouveau With Steam Linux Gaming
  2. Testing For The Latest Linux Kernel Power Regression
  3. The Most Energy Efficient Radeon GPU For AMD Linux Gaming
  4. 20-Way Radeon Comparison With Open-Source Graphics For Steam On Linux Gaming
Latest Linux News
  1. Getting Involved With The New Raspberry Pi Graphics Driver
  2. A New AMD Catalyst Linux Driver Unofficially Surfaces
  3. LibreOffice Ported To 64-bit ARM (AArch64)
  4. Enlightenment E19 RC3 Shows Off The New Wayland Compositor
  5. Metro Redux Is Going To Require OpenGL 4.x On Linux
  6. Jailhouse v0.1 Released As A Basic Hypervisor For Linux
  7. Google's Chromebook "Samus" Now Supported By Coreboot
  8. Chrome 38 Now In Beta With Exciting Advancements
  9. Ubuntu's Utopic Unicorn 14.10 Beta 1 Released
  10. Genode OS 14.08 Has New GUI Architecture, Pluggable VFS
Latest Forum Discussions
  1. Catalyst 14.201.1008
  2. Btrfs Gets Talked Up, Googler Encourages You To Try Btrfs
  3. It's Now Possible To Play Netflix Natively On Linux Without Wine Plug-Ins
  4. Users defect to Linux as OpenBSD removes Lynx from base system
  5. Updated and Optimized Ubuntu Free Graphics Drivers
  6. Canonical Joined The Khronos Group To Help Mir/Wayland Drivers
  7. Radeon HD5670 and Ubuntu 14.04
  8. AMD Releases UVD Video Decode Support For R600 GPUs