19.04.2016, 21:38, "Anders Carlsson" <ander...@apple.com>:
> 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), so
> we can capture move-only types in lambdas. According to
> https://gcc.gnu.org/projects/cxx-status.html that would require GCC 4.9.
This code compiles fine with GCC 4.8 with -std=c++1y flag:
auto f(std::unique_ptr<int> ptr)
{
[value = std::move(ptr)] {return *value;};
}
>
> - 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
--
Regards,
Konstantin
_______________________________________________
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev
