← Back to team overview

kicad-developers team mailing list archive

Re: -std=c++0x break build on MinGW and wxWidgets 2.9.4


On 11/14/2012 9:05 PM, Dick Hollenbeck wrote:


Really, even of you are inclined to say that MingW simply does not expose _strdup() or
strdup() when __STRICT_ANSI__
is defined, because of this in mingw's string.h:

#ifndef __STRICT_ANSI__

_CRTIMP char* __cdecl __MINGW_NOTHROW     _strdup (const char*) __MINGW_ATTRIB_MALLOC;


You still have to blame the wx folks for not working around the problem which pops up when
using -std=c++0x.

It looks like wx might be poised to provide their own

#ifndef wxCRT_StrdupA
WXDLLIMPEXP_BASE char *wxCRT_StrdupA(const char *psz);

under some circumstances.  This is one path to solution, but another one is to simply
provide a function prototype for _strdup() somewhere.  It is not like the function has
disappeared from MingW runtime libraries.  It is still there and you could link to it no

We could do one of these solutions but JP's commit using -std-gnuc++0x fixed this problem on MinGW but added it's own problem with the Boost polygon library. I also confirmed the Boost library problem exits on Linux using GCC 4.7.1 so I'm not sure the best course of action at this point. Do we remove the -std-gnuc++0x flag and use your original -std-c++0x flag and use one of the solutions you proposed or do we try to figure out why GCC 4.7.1 on Linux and GCC 4.7.2 on MinGW (most likely the 4.7 branch of GCC) fail to properly build Boost polygon. If I get some time tomorrow, I'll see if I can figure out the problem. At this point I cannot build KiCad on either platform.

Follow ups