Hi,
On Wed, Jul 17, 2019 at 01:24:26PM -0400, Seth Hillbrand wrote:
Any reason to be using the gnu++14 extensions? I thought we were
trying to stay with the vanilla c++14.
I went for consistency. This code is pretty much unused anyway, since
it
only handles the very old CMake versions that don't know the properties
--
that's why there is a version check in front that causes a fatal error
if
someone bumps the minimum CMake version without removing the
compatibility
code.
We currently have the respective compiler extensions enabled (both GNU
and
Visual Studio), because we don't have
set( CMAKE_CXX_EXTENSIONS OFF )
The problem is that doing that breaks msys2 builds with wx 3.0, because
gcc
provides a POSIX-compliant strlen implementation as an extension that
becomes unavailable in standards-compliant mode. A wx header decides to
redirect missing functions to replacements in the DLL, but building the
DLL
with extensions enabled means that the function is missing -- so builds
with -std=c++14 fail to link with a missing symbol.
I dimly remember that this is fixed in wx 3.1 (just provide the CRT
functions unconditionally), but I can't find the bug report anymore.
Simon
