> On Apr 19, 2016, at 11:33 AM, Konstantin Tokarev <annu...@yandex.ru> wrote: > > > > 19.04.2016, 21:15, "Filip Pizlo" <fpi...@apple.com <mailto: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? -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 <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 <mailto:webkit-dev@lists.webkit.org> >> https://lists.webkit.org/mailman/listinfo/webkit-dev >> <https://lists.webkit.org/mailman/listinfo/webkit-dev> > > -- > Regards, > Konstantin
_______________________________________________ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev