<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">I’d like us to switch over to using C++14 in WebKit2 so we can get the new generalized lambda capture (<a href="https://isocpp.org/files/papers/N3648.html" class="">https://isocpp.org/files/papers/N3648.html</a>), so we can capture move-only types in lambdas. According to <a href="https://gcc.gnu.org/projects/cxx-status.html" class="">https://gcc.gnu.org/projects/cxx-status.html</a> that would require GCC 4.9.<div class=""><br class=""></div><div class="">- Anders</div><div class=""><br class=""><div class=""><div><blockquote type="cite" class=""><div class="">On Apr 19, 2016, at 11:14 AM, Filip Pizlo <<a href="mailto:fpizlo@apple.com" class="">fpizlo@apple.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div class="">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:<br class=""><br class="">- Sometimes saying { } to initialize a variable doesn’t work.<br class="">- Sometimes you need to say “const”.<br class="">- Sometimes you need to play with variables to get around internal compiler errors.<br class=""><br class="">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?<br class=""><br class="">-Filip<br class=""><br class=""><br class=""><blockquote type="cite" class="">On Apr 19, 2016, at 11:02 AM, Michael Catanzaro <<a href="mailto:mcatanzaro@igalia.com" class="">mcatanzaro@igalia.com</a>> wrote:<br class=""><br class="">Hi,<br class=""><br class="">On Mon, 2016-04-18 at 17:27 -0700, Filip Pizlo wrote:<br class=""><blockquote type="cite" class="">I am sympathetic to the principle that we should support the<br class="">compilers that ship on the most popular versions of Linux.<br class=""></blockquote><br class="">Great. :)<br class=""><br class=""><blockquote type="cite" class="">I’d like to understand if that argument is sufficient to support GCC<br class="">4.8.<br class=""><br class="">Can you clarify, is it the case that if I installed the latest stable<br class="">Fedora, I’d get GCC 4.8?<br class=""></blockquote><br class="">No, all currently-supported versions of Fedora include GCC 5 (only).<br class="">Different distros have very different release cycles and policies for<br class="">compiler upgrades. Fedora releases roughly every six months, and each<br class="">release is supported for roughly 13 months. GCC releases once per year.<br class="">The GCC developers coordinate with Fedora release planning to time GCC<br class="">releases to coincide with spring Fedora releases; in the winter before<br class="">a new GCC release, we rebuilt all of Fedora with the GCC beta so the<br class="">GCC developers can collect bug reports. So we will never have issues<br class="">with Fedora, as the oldest Fedora will be at most one year behind<br class="">upstream GCC. (Note that I co-maintain the WebKitGTK+ package there and<br class="">I'm making sure all supported Fedoras get updates.)<br class=""><br class="">But Fedora is exceptional in this regard. Other distros are supported<br class="">for much longer than 13 months (5 years for Ubuntu LTS and newly also<br class="">for Debian, 10 years for enterprise distros) and therefore have much<br class="">older compilers. The question is where do we draw the line. We<br class="">obviously cannot support a 10 year old distro; those are maintained by<br class="">rich corporations, and if they cared about WebKit security, they could<br class="">take responsibility for that. We could handle 5 years, but do we really<br class="">want to? (It's clear Apple doesn't.) It's really inconvenient to not<br class="">have access to newer dependencies or language features for so long. We<br class="">might start by saying that we only support the latest release of [list<br class="">of major distros that have recently been shipping WebKit updates]. Most<br class="">of these distros are currently built using GCC 4.9, though they might<br class="">have GCC 5 or GCC 6 packaged as well, but not used by default. The big<br class="">one still using GCC 4.8 is openSUSE.<br class=""><br class="">We don't *need* to consider Ubuntu right now, because they rarely ever<br class="">take our updates, nor Debian, because they never take our updates. I<br class="">think WebKit updates for Debian is all but totally a lost cause, but<br class="">I'm kinda still hopeful for Ubuntu, so I'd like to keep them in mind.<br class=""><br class="">Also, different distros have different policies on using alternative<br class="">compilers. E.g. in Fedora we are usually required to always use<br class="">Fedora's GCC, and only one version is available at a time... but if a<br class="">package *really* has no chance of being built with GCC, we're allowed<br class="">to use Fedora's Clang instead. I'm not sure what the policies are for<br class="">Debian and Ubuntu, but they always have available a newer GCC than is<br class="">used for building packages, and until recently were using Clang to<br class="">build Chromium, so alternative compilers must be permitted at least in<br class="">exceptional cases. I was trying to convince the openSUSE folks to use<br class="">Clang to build WebKit, to avoid the GCC 4.8 issue, but they were not<br class="">enthusiastic. (But consider that all these distros will have older<br class="">versions of Clang as well.)<br class=""><br class="">Now, whether openSUSE is important enough on its own to justify holding<br class="">back or lowering our GCC requirement... maybe not. But anyway, since we<br class="">have significant contributors like Konstantin stuck with GCC 4.8, and<br class="">since this doesn't require giving up on any significant language<br class="">features, I think it's OK. If it's only a little work to support that<br class="">compiler (on the level we already have in trunk), I think it's a good<br class="">idea.<br class=""><br class="">But there is another problem here. openSUSE seems to have no intention<br class="">of upgrading to a newer GCC anytime soon, because they have started to<br class="">inherit core packages like GCC from the SUSE enterprise distro. So I<br class="">might need to negotiate with them if it would be possible to build<br class="">WebKit with clang after all.<br class=""><br class=""><blockquote type="cite" class="">Can you clarify what you mean by “backport”? I’m trying to get a<br class="">picture of how your releases work. For example, are you saying that<br class="">RHEL wouldn’t take a security update that you backported, or that<br class="">they won’t invest energy into backporting it themselves?<br class=""></blockquote><br class="">We don't try to convince distros to take individual security fixes as<br class="">patches, because there are way too many for that to be practical. We<br class="">want them to take our tarball updates.<br class=""><br class="">In that mail I was saying that RHEL won't invest energy into<br class="">backporting things themselves downstream; consider that we have about<br class="">100 security fixes per year, backporting from trunk needs to be handled<br class="">upstream so this can be shared among distros, rather than separately by<br class="">each distro that wants to provide WebKit updates. Our upstream<br class="">WebKitGTK+ releases work like this: every February and August, we<br class="">branch off of trunk; this forms a new stable branch, which gets<br class="">released in March/September. We then cherry-pick fixes to that branch<br class="">and make releases off of it for the next seven months or so. Our goal<br class="">is to convince distros to take these releases, because it's the only<br class="">practical way for them to get security updates. I've recently had some<br class="">mixed success with this; a couple big names like Mageia and openSUSE<br class="">recently started taking our updates.<br class=""><br class="">Some distros like Debian refuse to take any version upgrades at all,<br class="">and want to fix everything with downstream patches. Since that is not<br class="">practical for WebKit, they have adopted a policy of no security support<br class="">for WebKit. Ubuntu leans towards this as well, but occasionally they do<br class="">take our updates; I'm hoping that might become more common.<br class=""><br class="">(RHEL is a bit of a special case in that its old enough that all apps<br class="">in RHEL are using WebKit1, which we don't support anymore, so there's<br class="">no value in taking our updates.)<br class=""><br class=""><blockquote type="cite" class="">How many changes are required to make GCC 4.8 work? I think this<br class="">will provide important context for this discussion.<br class=""></blockquote><br class="">I guess it's working already and we only need to remove the build error<br class="">when it's detected, because Konstantin has been committing GCC 4.8<br class="">fixes throughout the tree:<br class=""><br class=""><a href="http://trac.webkit.org/search?q=4.8&noquickjump=1&changeset=on" class="">http://trac.webkit.org/search?q=4.8&noquickjump=1&changeset=on</a><br class=""><br class="">Anyway, I do not strongly request that we drop the GCC requirement to<br class="">GCC 4.8, though I think that would be fine; just please, we should keep<br class="">these issues in mind when upgrading our compiler requirement in the<br class="">future.<br class=""><br class="">Michael<br class=""></blockquote><br class="">_______________________________________________<br class="">webkit-dev mailing list<br class=""><a href="mailto:webkit-dev@lists.webkit.org" class="">webkit-dev@lists.webkit.org</a><br class="">https://lists.webkit.org/mailman/listinfo/webkit-dev<br class=""></div></div></blockquote></div><br class=""></div></div></body></html>