On 11/14/2012 9:05 PM, Dick Hollenbeck wrote:
https://groups.google.com/forum/?fromgroups=#!topic/wx-dev/XkXyvMZZpDs 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; #endif 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); #endif 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 problem.
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.
_______________________________________________ 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
