Bug 187744 – Switch CMake ports back to C++ 14

• Component: WebCore Misc.
• Status: RESOLVED FIXED

[Michael Catanzaro]

A few months ago, we switched CMake ports from C++ 14 to C++ 17. There have been some problems. Notably, we have not yet addressed the situation with std::optional. Misuse of std::optional that causes a runtime crash on GTK/WPE, when built with GCC 7 or 8, is still just a debug assert on Mac, bug #187669. This has been an ongoing problem for several months. I propose switching back to C++ 14 until this is resolved.

It's also worth pointing out that stuck supporting the GCC 5 libstdc++ for the foreseeable future, even though we require GCC 6 for actually compiling WebKit. This severely limits the benefit of using C++ 17 since we can't rely on any of the standard library features.

[Michael Catanzaro]

This turned out to be easy. It seems we are not using any C++ 17 features anywhere in the codebase. I guess it's not too surprising, since the XCode build is apparently still on C++ 14.

[Michael Catanzaro]

Created attachment 345218 [details]
Patch

[WebKit Commit Bot]

Comment on attachment 345218 [details]
Patch

Clearing flags on attachment: 345218

Committed r233912: <https://trac.webkit.org/changeset/233912>

[WebKit Commit Bot]

All reviewed patches have been landed.  Closing bug.

[Radar WebKit Bug Importer]

<rdar://problem/42334051>

[JF Bastien]

(In reply to Michael Catanzaro from comment #0)
> A few months ago, we switched CMake ports from C++ 14 to C++ 17. There have
> been some problems. Notably, we have not yet addressed the situation with
> std::optional. Misuse of std::optional that causes a runtime crash on
> GTK/WPE, when built with GCC 7 or 8, is still just a debug assert on Mac,
> bug #187669. This has been an ongoing problem for several months. I propose
> switching back to C++ 14 until this is resolved.

What are the associated bugs for this?

> It's also worth pointing out that stuck supporting the GCC 5 libstdc++ for
> the foreseeable future, even though we require GCC 6 for actually compiling
> WebKit. This severely limits the benefit of using C++ 17 since we can't rely
> on any of the standard library features.

What is the issue precisely? You can compiler with a newer libstdc++ and use the ABI compatibility macro to support older distros.

[Michael Catanzaro]

(In reply to JF Bastien from comment #6)
> (In reply to Michael Catanzaro from comment #0)
> > A few months ago, we switched CMake ports from C++ 14 to C++ 17. There have
> > been some problems. Notably, we have not yet addressed the situation with
> > std::optional. Misuse of std::optional that causes a runtime crash on
> > GTK/WPE, when built with GCC 7 or 8, is still just a debug assert on Mac,
> > bug #187669. This has been an ongoing problem for several months. I propose
> > switching back to C++ 14 until this is resolved.
> 
> What are the associated bugs for this?

Currently bug #187669, but for motivation, see also: bug #186536, bug #185159, bug #187672, bug #186189, bug #186535, bug #186752, bug #186753, bug #187139, bug #187145, bug #187243, bug #187382.

I think we can switch back to C++ 17 when bug #187669 is fixed, but I don't expect that to happen soon. Also, it'd be good to switch XCode at the same time.

> What is the issue precisely? You can compiler with a newer libstdc++ and use
> the ABI compatibility macro to support older distros.

That's what I had hoped, but sadly, the application will still be linked to the older system libstdc++, and apparently you can't static link to a newer libstdc++ and also dynamic link to the system version at the same time. At least, I've never seen anyone successfully accomplish this. So we have to treat libstdc++ as a runtime dependency. Under our current dependencies policy, we'd drop support for libstdc++ for GCC 5 one year after bumping the compiler requirement, i.e. April next year. But that will screw over Ubuntu 16.04, the first version of Ubuntu to provide security support for WebKit, which is supposed to be supported another two years after that. So we'll have to figure out what we are going to do here.