[webkit-dev] Build slave for JSCOnly Linux MIPS
mcatanzaro at igalia.com
Tue Apr 19 11:02:57 PDT 2016
On Mon, 2016-04-18 at 17:27 -0700, Filip Pizlo wrote:
> I am sympathetic to the principle that we should support the
> compilers that ship on the most popular versions of Linux.
> I’d like to understand if that argument is sufficient to support GCC
> Can you clarify, is it the case that if I installed the latest stable
> Fedora, I’d get GCC 4.8?
No, all currently-supported versions of Fedora include GCC 5 (only).
Different distros have very different release cycles and policies for
compiler upgrades. Fedora releases roughly every six months, and each
release is supported for roughly 13 months. GCC releases once per year.
The GCC developers coordinate with Fedora release planning to time GCC
releases to coincide with spring Fedora releases; in the winter before
a new GCC release, we rebuilt all of Fedora with the GCC beta so the
GCC developers can collect bug reports. So we will never have issues
with Fedora, as the oldest Fedora will be at most one year behind
upstream GCC. (Note that I co-maintain the WebKitGTK+ package there and
I'm making sure all supported Fedoras get updates.)
But Fedora is exceptional in this regard. Other distros are supported
for much longer than 13 months (5 years for Ubuntu LTS and newly also
for Debian, 10 years for enterprise distros) and therefore have much
older compilers. The question is where do we draw the line. We
obviously cannot support a 10 year old distro; those are maintained by
rich corporations, and if they cared about WebKit security, they could
take responsibility for that. We could handle 5 years, but do we really
want to? (It's clear Apple doesn't.) It's really inconvenient to not
have access to newer dependencies or language features for so long. We
might start by saying that we only support the latest release of [list
of major distros that have recently been shipping WebKit updates]. Most
of these distros are currently built using GCC 4.9, though they might
have GCC 5 or GCC 6 packaged as well, but not used by default. The big
one still using GCC 4.8 is openSUSE.
We don't *need* to consider Ubuntu right now, because they rarely ever
take our updates, nor Debian, because they never take our updates. I
think WebKit updates for Debian is all but totally a lost cause, but
I'm kinda still hopeful for Ubuntu, so I'd like to keep them in mind.
Also, different distros have different policies on using alternative
compilers. E.g. in Fedora we are usually required to always use
Fedora's GCC, and only one version is available at a time... but if a
package *really* has no chance of being built with GCC, we're allowed
to use Fedora's Clang instead. I'm not sure what the policies are for
Debian and Ubuntu, but they always have available a newer GCC than is
used for building packages, and until recently were using Clang to
build Chromium, so alternative compilers must be permitted at least in
exceptional cases. I was trying to convince the openSUSE folks to use
Clang to build WebKit, to avoid the GCC 4.8 issue, but they were not
enthusiastic. (But consider that all these distros will have older
versions of Clang as well.)
Now, whether openSUSE is important enough on its own to justify holding
back or lowering our GCC requirement... maybe not. But anyway, since we
have significant contributors like Konstantin stuck with GCC 4.8, and
since this doesn't require giving up on any significant language
features, I think it's OK. If it's only a little work to support that
compiler (on the level we already have in trunk), I think it's a good
But there is another problem here. openSUSE seems to have no intention
of upgrading to a newer GCC anytime soon, because they have started to
inherit core packages like GCC from the SUSE enterprise distro. So I
might need to negotiate with them if it would be possible to build
WebKit with clang after all.
> Can you clarify what you mean by “backport”? I’m trying to get a
> picture of how your releases work. For example, are you saying that
> RHEL wouldn’t take a security update that you backported, or that
> they won’t invest energy into backporting it themselves?
We don't try to convince distros to take individual security fixes as
patches, because there are way too many for that to be practical. We
want them to take our tarball updates.
In that mail I was saying that RHEL won't invest energy into
backporting things themselves downstream; consider that we have about
100 security fixes per year, backporting from trunk needs to be handled
upstream so this can be shared among distros, rather than separately by
each distro that wants to provide WebKit updates. Our upstream
WebKitGTK+ releases work like this: every February and August, we
branch off of trunk; this forms a new stable branch, which gets
released in March/September. We then cherry-pick fixes to that branch
and make releases off of it for the next seven months or so. Our goal
is to convince distros to take these releases, because it's the only
practical way for them to get security updates. I've recently had some
mixed success with this; a couple big names like Mageia and openSUSE
recently started taking our updates.
Some distros like Debian refuse to take any version upgrades at all,
and want to fix everything with downstream patches. Since that is not
practical for WebKit, they have adopted a policy of no security support
for WebKit. Ubuntu leans towards this as well, but occasionally they do
take our updates; I'm hoping that might become more common.
(RHEL is a bit of a special case in that its old enough that all apps
in RHEL are using WebKit1, which we don't support anymore, so there's
no value in taking our updates.)
> How many changes are required to make GCC 4.8 work? I think this
> will provide important context for this discussion.
I guess it's working already and we only need to remove the build error
when it's detected, because Konstantin has been committing GCC 4.8
fixes throughout the tree:
Anyway, I do not strongly request that we drop the GCC requirement to
GCC 4.8, though I think that would be fine; just please, we should keep
these issues in mind when upgrading our compiler requirement in the
More information about the webkit-dev