[webkit-dev] Build slave for JSCOnly Linux MIPS

Tue Apr 19 11:34:45 PDT 2016

> On Apr 19, 2016, at 11:33 AM, Konstantin Tokarev <annulen at yandex.ru> wrote:
> 
> 
> 
> 19.04.2016, 21:15, "Filip Pizlo" <fpizlo at apple.com <mailto:fpizlo at apple.com>>:
>> 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?
> 
> According to [1], GCC provides complete C++11 feature list since 4.8.1. However, it fails to compile FTLLazySlowPathCall.h, see complete set of diagnostics in [2].

Ouch!  Is there a bug for this?

-Filip

> 
> There is another minor bug: 4.8 does not allow aggregate initialization for structs which have deleted constructors [3].
> 
> [1] https://gcc.gnu.org/projects/cxx-status.html#cxx11 <https://gcc.gnu.org/projects/cxx-status.html#cxx11>
> [2] http://pastebin.com/ikyDTZ9s <http://pastebin.com/ikyDTZ9s>
> [3] https://bugs.webkit.org/show_bug.cgi?id=155698 <https://bugs.webkit.org/show_bug.cgi?id=155698>
>    https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52707 <https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52707>
> 
>> 
>> -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 <mailto:webkit-dev at lists.webkit.org>
>> https://lists.webkit.org/mailman/listinfo/webkit-dev <https://lists.webkit.org/mailman/listinfo/webkit-dev>
> 
> -- 
> Regards,
> Konstantin

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