19.04.2016, 21:34, "Filip Pizlo" <fpi...@apple.com>: >> On Apr 19, 2016, at 11:33 AM, Konstantin Tokarev <annu...@yandex.ru> wrote: >> >> 19.04.2016, 21:15, "Filip Pizlo" <fpi...@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?
GCC bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=47226 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=41933 No WebKit bug because GCC 4.8 was not officially supported > > -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 >> [2] http://pastebin.com/ikyDTZ9s >> [3] https://bugs.webkit.org/show_bug.cgi?id=155698 >> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52707 >> >>> -Filip >>> >>>> On Apr 19, 2016, at 11:02 AM, Michael Catanzaro <mcatanz...@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@lists.webkit.org >>> https://lists.webkit.org/mailman/listinfo/webkit-dev >> >> -- >> Regards, >> Konstantin -- Regards, Konstantin _______________________________________________ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev