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 <fpi...@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 <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
_______________________________________________ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev