kicad-developers team mailing list archive
-
kicad-developers team
-
Mailing list archive
-
Message #09146
Re: -std=c++0x break build on MinGW and wxWidgets 2.9.4
> Just a heads up for anyone who attempts to build testing r3800 on
> Windows with MinGW (GCC 4.7.2) and wxWidgets 2.9.4, you will get the
> following build errors everywhere <wx/string.h> is included in the source:
>
> /mingw/include/wx-2.9/wx/wxcrtbase.h: In function 'char* wxStrdup(const
> char*)':
> /mingw/include/wx-2.9/wx/wxcrtbase.h:697:62: error: '_strdup' was not
> declared in this scope
> /mingw/include/wx-2.9/wx/wxcrtbase.h: In function 'wchar_t*
> wxStrdup(const wchar_t*)':
> /mingw/include/wx-2.9/wx/wxcrtbase.h:698:68: error: 'wcsdup' was not
> declared in this scope
>
> and:
>
> /mingw/include/wx-2.9/wx/string.h: In function 'int Stricmp(const char*,
> const char*)':
> /mingw/include/wx-2.9/wx/string.h:174:31: error: 'strcasecmp' was not
> declared in this scope
> make[2]: ***
> [common/CMakeFiles/common.dir/dialog_about/AboutDialog_main.cpp.obj] Error 1
> [ 43%] Building CXX object
> common/CMakeFiles/common.dir/dialog_about/dialog_about.cpp.obj
>
> My guess is that _strdup, wcsdup, and strcasecmp are wrapped in an
> #ifdef/#endif block in the MinGW header files that undefines these
> functions when the -std=++0x flag is used. I confirmed this by
> commenting out the line in the main CMakeList.txt file. Obviously this
> also fails due to the new std::unique_ptr calls which require the
> -std=c++0x flag. So I attempted to rebuild wxWidgets 2.9.4 with
> -std=c++0x defined and got this error message:
Maybe we should just talk about building KiCad, not re-building wxWidgets yet.
So, speaking only about building KiCad now, on MingW:
I see these lines at line 49 in wxcrtbase.h
/*
Using -std=c++{98,0x} option with mingw32 disables most of standard
library extensions, so we can't rely on the presence of common non-ANSI
functions, define a special symbol to test for this. Notice that this
doesn't need to be done for g++ under Linux where _GNU_SOURCE (which is
defined by default) still makes all common extensions available even in
ANSI mode.
*/
#if defined(__MINGW32__) && defined(__STRICT_ANSI__)
#define __WX_STRICT_ANSI_GCC__
#endif
This says that __WX_STRICT_ANSI_GCC__ is intended to be an aid to this problem. But then
you look further down at line 167:
/* Almost all compiler have strdup(), but VC++ for CE doesn't provide it.
Another special case is gcc in strict ANSI mode: normally it doesn't provide
strdup() but MinGW does provide it under MSVC-compatible name so test for it
before checking __WX_STRICT_ANSI_GCC__. */
#if (defined(__VISUALC__) && __VISUALC__ >= 1400) || \
defined(__MINGW32__)
#define wxCRT_StrdupA _strdup
#elif !(defined(__WXWINCE__) || defined(__WX_STRICT_ANSI_GCC__))
#define wxCRT_StrdupA strdup
#endif
I think this could be a bug in wxcrtbase.h, this block at 167.
Maybe the order of tests is backwards, they should be trusting their
__WX_STRICT_ANSI_GCC__ define set earlier first. It would seem that strdup() should be in
play here, not _strdup() according to the comments at line 49. Almost certainly strdup()
exists as well as _strdup() on MingW runtime. But MingW does not want you using the
Microsoft _strdup() if you intend to go strict ANSI. No problem with MingW here, just
with wx header I think.
Try redoing the logic at line 167 by doing the 2nd test first.
#elif becomes #if and moved up.
If that does not work, I will see if I can duplicate this problem using MingW on Linux to
help out.
Dick
Follow ups
References