kicad-developers team mailing list archive

[Simon Richter <Simon.Richter@xxxxxxxxxx>]

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