[webkit-dev] Build slave for JSCOnly Linux MIPS

Tue Apr 19 11:37:48 PDT 2016

I’d like us to switch over to using C++14 in WebKit2 so we can get the new generalized lambda capture (https://isocpp.org/files/papers/N3648.html <https://isocpp.org/files/papers/N3648.html>), so we can capture move-only types in lambdas. According to https://gcc.gnu.org/projects/cxx-status.html <https://gcc.gnu.org/projects/cxx-status.html> that would require GCC 4.9.

- Anders

> On Apr 19, 2016, at 11:14 AM, Filip Pizlo <fpizlo at apple.com> wrote:
> 
> I did a quick look over the trac query of GCC 4.8 changes that you provided.  None of the ones I looked at were scary but they were annoying.  They seemed to be things like:
> 
> - Sometimes saying { } to initialize a variable doesn’t work.
> - Sometimes you need to say “const”.
> - Sometimes you need to play with variables to get around internal compiler errors.
> 
> I didn’t find any cases of GCC 4.8 not supporting a language feature that we want to use.  Do you think that’s correct?
> 
> -Filip
> 
> 
>> On Apr 19, 2016, at 11:02 AM, Michael Catanzaro <mcatanzaro at igalia.com> wrote:
>> 
>> Hi,
>> 
>> 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.
>> 
>> Great. :)
>> 
>>> I’d like to understand if that argument is sufficient to support GCC
>>> 4.8.
>>> 
>>> 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
>> idea.
>> 
>> 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:
>> 
>> http://trac.webkit.org/search?q=4.8&noquickjump=1&changeset=on
>> 
>> 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
>> future.
>> 
>> Michael
> 
> _______________________________________________
> webkit-dev mailing list
> webkit-dev at lists.webkit.org
> https://lists.webkit.org/mailman/listinfo/webkit-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.webkit.org/pipermail/webkit-dev/attachments/20160419/c97c0e68/attachment.html>