Setting C++ standard for wxWidgets with MinGW: gnu++ vs c++
282 views
Skip to first unread message
PB
Jan 19, 2017, 8:50:02 AM1/19/17
to wx-users
Hello
In WXWIN\docs\MSW\install.txt there is a long standing notice which reads:
On the other hand in a blog entry posted in June 2015 Vadim Zeitlin wrote:
I do understand that per the official install instructions the use of std=c++11 is not supported. But from the above-linked blog entry it seems that there is demand for wxWidgets being able to compile with std=c++ and perhaps someone knowledgeable may find an easy way to make it work. Of course, it is possible (likely?) that more errors like this one will pop up...
Regards
PB
In WXWIN\docs\MSW\install.txt there is a long standing notice which reads:
C++11 note: If you want to compile wxWidgets in C++11 mode, you currently have
to use -std=gnu++11 switch as -std=c++11 disables some extensions
that wxWidgets relies on. I.e. please use CXXFLAGS="-std=gnu++11".
On the other hand in a blog entry posted in June 2015 Vadim Zeitlin wrote:
The summary is that now building with all 3 compilers with and without -std=c++11 works.
Where by "3 compilers" he meant TDM-GCC, mingw-w64 and the "classic" MinGW. I wondered which statement was more accurate (and whether the install.txt should be perhaps updated).
When building the wxWidgets master branch head (with the recent GCC fixes) with the "classic" MinGW (GCC 5.3.0; installed via mingw-get-setup.exe downloaded from https://sourceforge.net/projects/mingw/) using
When building the wxWidgets master branch head (with the recent GCC fixes) with the "classic" MinGW (GCC 5.3.0; installed via mingw-get-setup.exe downloaded from https://sourceforge.net/projects/mingw/) using
mingw32-make -f makefile.gcc BUILD=debug CXXFLAGS="-std=gnu++11"
the build finished successfully. When I tried
mingw32-make -f makefile.gcc BUILD=debug CXXFLAGS="-std=c++11"
I ended up with an error:
g++ -c -o gcc_mswud\baselib_any.o -g -O0 -mthreads -DHAVE_W32API_H -D__WXMSW__
-D_UNICODE -I..\..\lib\gcc_lib\mswud -I..\..\include -W -Wall -DWXBUILDIN
G -I..\..\src\tiff\libtiff -I..\..\src\jpeg -I..\..\src\png -I..\..\src\zlib -I.
.\..\src\regex -I..\..\src\expat\lib -DwxUSE_GUI=0 -DwxUSE_BASE=1 -Wno-ctor-dt
or-privacy -std=c++11 -MTgcc_mswud\baselib_any.o -MFgcc_mswud\baselib_any.o.d -
MD -MP ../../src/common/any.cpp
In file included from ..\..\include/wx/crt.h:19:0,
from ../../src/common/any.cpp:24:
..\..\include/wx/wxcrt.h: In function 'long long int wxStrtoll(const char*, char
**, int)':
..\..\include/wx/wxcrt.h:876:42: error: 'strtoll' was not declared in this scope
{ return implA(nptr, endptr, base); } \
^
..\..\include/wx/wxcrt.h:902:1: note: in expansion of macro 'WX_STRTOX_FUNC'
WX_STRTOX_FUNC(wxLongLong_t, wxStrtoll, wxCRT_StrtollA, wxCRT_StrtollW)
^
..\..\include/wx/wxcrt.h: In function 'long long unsigned int wxStrtoull(const c
har*, char**, int)':
..\..\include/wx/wxcrt.h:876:42: error: 'strtoull' was not declared in this scop
e
{ return implA(nptr, endptr, base); } \
^
..\..\include/wx/wxcrt.h:903:1: note: in expansion of macro 'WX_STRTOX_FUNC'
WX_STRTOX_FUNC(wxULongLong_t, wxStrtoull, wxCRT_StrtoullA, wxCRT_StrtoullW)
^
makefile.gcc:12018: recipe for target 'gcc_mswud\baselib_any.o' failed
mingw32-make: *** [gcc_mswud\baselib_any.o] Error 1
I do understand that per the official install instructions the use of std=c++11 is not supported. But from the above-linked blog entry it seems that there is demand for wxWidgets being able to compile with std=c++ and perhaps someone knowledgeable may find an easy way to make it work. Of course, it is possible (likely?) that more errors like this one will pop up...
Regards
PB
papa
Jan 20, 2017, 5:34:35 AM1/20/17
to wx-u...@googlegroups.com
wxWidgets seems to be in a perpetual infant state.
Documentation:
When researching how to compile the toolkit one finds that a lot
of people, with a lot of different ideas, have come up with
different ways to compile the toolkit. The online documentation
provided by wxWidgets is at best very poor, and/or misleading.
Mailing list:
wxWidgets the support/help in this mailing list is so out of wack
that I have even been suggested to learn C/C++ to compile the
toolkit, a compilation that has nothing to do with C/C++
programming at all, but with whatever Compiler flavour one is
using.
Videos:
There are some videos on the net, but they present solutions that
are archaic.
After weeks reading about the toolkit and trying to get wxWidgets 3.0.x to work on a Win10 machine, my conclusion was that the toolkit presents great opportunities in a industrial strength manner, but the installation is too elegant, too arrogant and too capricious to make it worthwhile. So, for the time being I am not recommending the toolkit to my clients, but I am keeping an eye on developers who would tell their success stories and might also be willing to share them in detail.
Please, keep up the good work and document your story as much as possible, it might be that your research will make this beautiful toolkit finally take off and be use by more developers who will in turn recommend it to others.
A word of advice, the support on this mailing list might turn out
to be ambiguous. *Be Careful*
--
Please read http://www.wxwidgets.org/support/mlhowto.htm before posting.
To unsubscribe, send email to wx-users+u...@googlegroups.com
or visit http://groups.google.com/group/wx-users
|
This email has been checked for viruses by Avast antivirus software.
|
Andy Robinson
Jan 20, 2017, 6:18:38 AM1/20/17
to wx-u...@googlegroups.com
On 20/01/17 10:34, papa wrote:
> After weeks reading about the toolkit and trying to get wxWidgets 3.0.x
> to work on a Win10 machine, my conclusion was that the toolkit presents
> great opportunities in a industrial strength manner, but the
> installation is too elegant, too arrogant and too capricious to make it
> worthwhile. So, for the time being I am not recommending the toolkit to
> my clients, but I am keeping an eye on developers who would tell their
> success stories and might also be willing to share them in detail.
>
> Please, keep up the good work and document your story as much as
> possible, it might be that your research will make this beautiful
> toolkit finally take off and be use by more developers who will in turn
> recommend it to others.
I've been using wxWindows since 2003 with great success on Windows, Mac
> After weeks reading about the toolkit and trying to get wxWidgets 3.0.x
> to work on a Win10 machine, my conclusion was that the toolkit presents
> great opportunities in a industrial strength manner, but the
> installation is too elegant, too arrogant and too capricious to make it
> worthwhile. So, for the time being I am not recommending the toolkit to
> my clients, but I am keeping an eye on developers who would tell their
> success stories and might also be willing to share them in detail.
>
> Please, keep up the good work and document your story as much as
> possible, it might be that your research will make this beautiful
> toolkit finally take off and be use by more developers who will in turn
> recommend it to others.
and Linux.
If the documentation isn't perfect, and the discussion group sometimes
receives contradictory postings, I'd say that's pretty normal for any
open source project.
Regards,
Andy Robinson, Seventh String Software, www.seventhstring.com
PB
Jan 20, 2017, 7:10:11 AM1/20/17
to wx-users
Hello
Please notice that the "issue" I was writing about in the OP manifested only when I intentionally did something which according to the official documentation I should not do. Therefore I did not consider it a bug, I would have filled a ticket on wxTrac otherwise.
Regarding wxWidgets compilation in general.... I can speak only for Windows but I am not a programmer nor a smart or educated person yet I have never encountered any real problems when building wxWidgets, originally using MSVC 6, now MSVC 14. I usually use provided MSVC makefiles which make the whole procedure quite customizable while still being extremely simple. I believe the documentation provided (in install.txt) is very clear and as long as one follows it there should be no issues. With MinGW it gets more complicated due to there being several flavours and versions in the wild but I guess it is still at least good enough. Of course one may run into some edge case with any build environment but from my not so insignificant experience from 7 years on wxForums, the problem is quite often right between the keyboard and the chair.
I have to admit that I do not understand why a person not familiar with C++ should be required to build a C++ toolkit but I do understand that for such people it may be difficult as they are likely to lack even the basic knowledge how C++ libraries are built and work.
BTW: AFAIK, there is CMake support to be added soon which may make the building process even simpler and user friendlier (among else e.g. allow generating project for samples also for IDEs such as CodeLite or Code::Blocks) .
Regards, PB
Please notice that the "issue" I was writing about in the OP manifested only when I intentionally did something which according to the official documentation I should not do. Therefore I did not consider it a bug, I would have filled a ticket on wxTrac otherwise.
Regarding wxWidgets compilation in general.... I can speak only for Windows but I am not a programmer nor a smart or educated person yet I have never encountered any real problems when building wxWidgets, originally using MSVC 6, now MSVC 14. I usually use provided MSVC makefiles which make the whole procedure quite customizable while still being extremely simple. I believe the documentation provided (in install.txt) is very clear and as long as one follows it there should be no issues. With MinGW it gets more complicated due to there being several flavours and versions in the wild but I guess it is still at least good enough. Of course one may run into some edge case with any build environment but from my not so insignificant experience from 7 years on wxForums, the problem is quite often right between the keyboard and the chair.
I have to admit that I do not understand why a person not familiar with C++ should be required to build a C++ toolkit but I do understand that for such people it may be difficult as they are likely to lack even the basic knowledge how C++ libraries are built and work.
BTW: AFAIK, there is CMake support to be added soon which may make the building process even simpler and user friendlier (among else e.g. allow generating project for samples also for IDEs such as CodeLite or Code::Blocks) .
Regards, PB
Catalin
Jan 20, 2017, 7:13:45 AM1/20/17
to wx-u...@googlegroups.com
Hello,
This email, beside being off topic, is so wrong at places that IMO it needs to be said.
On Friday, 20 January 2017, 12:42, papa wrote:
> wxWidgets seems to be in a perpetual infant state.
Personally, I simply disagree. I don't know what "infant state" is to you, but if companies like Google find it good enough for million user software (see Drive), I guess it's not _that_ bad.
> When researching how to compile the toolkit one finds that a lot
of people, with a lot of different ideas, have come up with
different ways to compile the toolkit.
Did you bother to research the documentation included with the source files ? i.e. docs/*/install.txt? Because you'll see that in some configurations they are ridiculously simple, like requiring only a few mouse clicks (MSW and VS).
You probably don't realize that the vast majority of people that do compile the toolkit without issues will not post saying "oh goodie, it worked!".
> The online documentation
provided by wxWidgets is at best very poor, and/or misleading.
If you're referring to wiki pages, well, they are bound to get old and by definition they can be updated by anyone, including you.
But, do you have any examples of such "documentation" ? Because - again -, it is not quite so, IMO.
> wxWidgets the support/help in this mailing list is so out of wack
that I have even been suggested to learn C/C++ to compile the
toolkit, a compilation that has nothing to do with C/C++
programming at all, but with whatever Compiler flavour one is
using.
It may have happened that you did not get a useful advise, but so many people did, that your statement about this mailing list is simply false.
And if I may, it's not totally wacky to require some C/C++ knowledge even when compiling the toolkit. It all depends on what you asked, i.e. what if you need to decide whether you should use c++11 or c++14 compliance, or not?
> There are some videos on the net, but they present solutions that
are archaic.
..then find some that are more actual. They definitely are out there.
> After weeks reading about the toolkit and trying to get wxWidgets
3.0.x to work on a Win10 machine
No, really, you spent weeks trying to get wxWidgets 3.0.x to work on a Win10 machine? What exactly did you do for so long?
Because if there are real issues that lead to this, they are definitely worth knowing and worth at least a wiki article, probably with "don't"-s...
> my conclusion was that the
toolkit presents great opportunities in a industrial strength
manner, but the installation is too elegant, too arrogant and too
capricious to make it worthwhile. So, for the time being I am not
recommending the toolkit to my clients
See above about the installation ("too elegant [...] to make it worthwhile"? ...come on...)
> the support on this mailing list might turn out
to be ambiguous. *Be Careful*
Yes, this is a mailing list and anybody can reply to your emails. But not everyone will give you the best advice. Maybe reading a week's worth of emails will help you separate the posters that give useful advices from the ones that mostly make noise. So yeah, why not, be careful, but also be realistic about it.
Regards,
C
Manolo
Jan 20, 2017, 1:54:46 PM1/20/17
to wx-users, pa...@arbolone.ca
I started with C++ about 2000. An with wxWidgets, and its mailing lists, about 2001. This is the first time I read somebody saying wx is "too" whatever. And also "beautiful" things like arrogant or capricious.
I can understand that when something goes hard, the easiest is to put the blame on someone else. But if you consider how much people succeed in doing it, then it's you who is failng.
When you, papa, has asked for help installing or compiling or C::B etc, several persons (myself included) have tried to help you. Your response has been continue complaining.
You are not the first who struggles with some part. May be docs, may be some configuration, or some class. Most of people gets useful help here or in the forum. Why do you think you don't get it?. All of it for free...
Anyhow, if you post a defined question, I'll try to help.
I can understand that when something goes hard, the easiest is to put the blame on someone else. But if you consider how much people succeed in doing it, then it's you who is failng.
When you, papa, has asked for help installing or compiling or C::B etc, several persons (myself included) have tried to help you. Your response has been continue complaining.
You are not the first who struggles with some part. May be docs, may be some configuration, or some class. Most of people gets useful help here or in the forum. Why do you think you don't get it?. All of it for free...
Anyhow, if you post a defined question, I'll try to help.
Vadim Zeitlin
Jan 20, 2017, 3:26:35 PM1/20/17
to wx-u...@googlegroups.com
On Thu, 19 Jan 2017 05:50:02 -0800 (PST) PB wrote:
P> On the other hand in a blog entry posted in June 2015
P> <http://wxwidgets.blogspot.com/2015/06/build-fixes-for-different-gcc.html>
P> Vadim Zeitlin wrote:
P>
P> > The summary is that now building with all 3 compilers with and without
P> > -std=c++11 works.
P>
P> Where by "3 compilers" he meant TDM-GCC, mingw-w64 and the "classic" MinGW.
P> I wondered which statement was more accurate (and whether the install.txt
P> should be perhaps updated).
P>
P> When building the wxWidgets master branch head (with the recent GCC fixes)
P> with the "classic" MinGW (GCC 5.3.0; installed via mingw-get-setup.exe
P> downloaded from https://sourceforge.net/projects/mingw/) using
P>
P> > mingw32-make -f makefile.gcc BUILD=debug CXXFLAGS="-std=gnu++11"
P> >
P> the build finished successfully. When I tried
P>
P> > mingw32-make -f makefile.gcc BUILD=debug CXXFLAGS="-std=c++11"
P>
P> I ended up with an error:
...
P> > ..\..\include/wx/wxcrt.h:876:42: error: 'strtoll' was not declared in this
P> > scope
Thanks, I see it too. Unfortunately this compiler (MinGW 5.3) seems to be
much more broken than average because it's another (in addition to those
fixed by https://github.com/wxWidgets/wxWidgets/commit/0b6319b5) bug in it.
I've reported it, but for now we need a fix, so I committed a workaround
for this (and several other) missing declarations in
https://github.com/wxWidgets/wxWidgets/commit/26c30949
Unfortunately it looks like we're going to need to copy half of standard
headers into our own ones to support MinGW in strict C++11 mode if it
continues like this :-(
P> I do understand that per the official install instructions the use of
P> std=c++11 is not supported. But from the above-linked blog entry it seems
P> that there is demand for wxWidgets being able to compile with std=c++ and
P> perhaps someone knowledgeable may find an easy way to make it work. Of
P> course, it is possible (likely?) that more errors like this one will pop
P> up...
Yes, this is exactly what happened. I did make an effort to make building
with -std=c++11 work because people "naively" expect it to, but this got
broken by the very next compiler release and this will definitely happen
again. The only thing we could do would be to set up build slaves checking
that it doesn't happen, but someone would have to do it.
FWIW, I don't use MinGW that much myself and when I do, I strongly prefer
to cross-compile from Linux. But if you do have to use it natively, IME the
most reasonable distribution is TDM-GCC. MinGW-w64 is actively developed,
but some of their decisions look very questionable to me. As for the
classic MinGW, I thought the project was simply dead and replaced by
MinGW-w64 which turned out to be wrong -- but this latest 5.3 release is
really poor and I can't recommend using it.
Regards,
VZ
--
TT-Solutions: wxWidgets consultancy and technical support
http://www.tt-solutions.com/
P> On the other hand in a blog entry posted in June 2015
P> <http://wxwidgets.blogspot.com/2015/06/build-fixes-for-different-gcc.html>
P> Vadim Zeitlin wrote:
P>
P> > The summary is that now building with all 3 compilers with and without
P> > -std=c++11 works.
P>
P> Where by "3 compilers" he meant TDM-GCC, mingw-w64 and the "classic" MinGW.
P> I wondered which statement was more accurate (and whether the install.txt
P> should be perhaps updated).
P>
P> When building the wxWidgets master branch head (with the recent GCC fixes)
P> with the "classic" MinGW (GCC 5.3.0; installed via mingw-get-setup.exe
P> downloaded from https://sourceforge.net/projects/mingw/) using
P>
P> > mingw32-make -f makefile.gcc BUILD=debug CXXFLAGS="-std=gnu++11"
P> >
P> the build finished successfully. When I tried
P>
P> > mingw32-make -f makefile.gcc BUILD=debug CXXFLAGS="-std=c++11"
P>
P> I ended up with an error:
...
P> > ..\..\include/wx/wxcrt.h:876:42: error: 'strtoll' was not declared in this
P> > scope
Thanks, I see it too. Unfortunately this compiler (MinGW 5.3) seems to be
much more broken than average because it's another (in addition to those
fixed by https://github.com/wxWidgets/wxWidgets/commit/0b6319b5) bug in it.
I've reported it, but for now we need a fix, so I committed a workaround
for this (and several other) missing declarations in
https://github.com/wxWidgets/wxWidgets/commit/26c30949
Unfortunately it looks like we're going to need to copy half of standard
headers into our own ones to support MinGW in strict C++11 mode if it
continues like this :-(
P> I do understand that per the official install instructions the use of
P> std=c++11 is not supported. But from the above-linked blog entry it seems
P> that there is demand for wxWidgets being able to compile with std=c++ and
P> perhaps someone knowledgeable may find an easy way to make it work. Of
P> course, it is possible (likely?) that more errors like this one will pop
P> up...
Yes, this is exactly what happened. I did make an effort to make building
with -std=c++11 work because people "naively" expect it to, but this got
broken by the very next compiler release and this will definitely happen
again. The only thing we could do would be to set up build slaves checking
that it doesn't happen, but someone would have to do it.
FWIW, I don't use MinGW that much myself and when I do, I strongly prefer
to cross-compile from Linux. But if you do have to use it natively, IME the
most reasonable distribution is TDM-GCC. MinGW-w64 is actively developed,
but some of their decisions look very questionable to me. As for the
classic MinGW, I thought the project was simply dead and replaced by
MinGW-w64 which turned out to be wrong -- but this latest 5.3 release is
really poor and I can't recommend using it.
Regards,
VZ
--
TT-Solutions: wxWidgets consultancy and technical support
http://www.tt-solutions.com/
PB
Jan 20, 2017, 3:55:29 PM1/20/17
to wx-users
Thanks for the reply Vadim. I actually use MSVC as my compiler of choice but I use a GCC-based toolchain here and there to test some of my code, usually TDM-GCC. I just wanted to try vanilla MinGW for a change, being blissfully unaware about its many issues. I had no idea that GCC-based build toolchains on MSW are generally in not so good state. While TDM-GCC appears to be the best of the three; seeing its last update is from the summer of 2015, it does not look that well for it either but perhaps there is no need to update it...
Regards, PB
Regards, PB
Fulvio Senore
Jan 21, 2017, 3:55:29 AM1/21/17
to wx-u...@googlegroups.com
Il 20/01/2017 11:34, papa ha scritto:
>
> After weeks reading about the toolkit and trying to get wxWidgets 3.0.x
> to work on a Win10 machine, my conclusion was that the toolkit presents
> great opportunities in a industrial strength manner, but the
> installation is too elegant, too arrogant and too capricious to make it
> worthwhile. So, for the time being I am not recommending the toolkit to
> my clients, but I am keeping an eye on developers who would tell their
> success stories and might also be willing to share them in detail.
>
It's interesting how (non only in the computer programming field)
>
> After weeks reading about the toolkit and trying to get wxWidgets 3.0.x
> to work on a Win10 machine, my conclusion was that the toolkit presents
> great opportunities in a industrial strength manner, but the
> installation is too elegant, too arrogant and too capricious to make it
> worthwhile. So, for the time being I am not recommending the toolkit to
> my clients, but I am keeping an eye on developers who would tell their
> success stories and might also be willing to share them in detail.
>
sometimes people cannot complete tasks that have been successfully
completed by thousands other people before them.
Most often those people blame the tools that they are using and
everything except themselves, and they are never touched by the thought
that maybe that task is too hard for their knowledge.
Getting wxWidgets to work on a Windows machine? Come on, Windows is the
dominant OS: almost every wxWidgets user has done that.
Ask yourself why you cannot do what everybody else can.
Best regards
Fulvio
Reply all
Reply to author
Forward
0 new messages