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 _______________________________________________ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp