errors building wxWidgets in C++11 mode
Nathan Ridge
Hello,
I am trying to build wxWidgets with GCC in C++11 mode (that is, by passing
CXXFLAGS=--std=c++11 to configure), but I am getting the following errors
when compiling src/common/translation.cpp:
In file included from ../include/wx/wx.h:21:0,
from ../include/wx/wxprec.h:58:
../include/wx/hashmap.h:594:1: error: 'class wxStringHash wxStringHash::wxStringHash' is inaccessible
../src/common/translation.cpp:1443:1: error: within this context
In file included from ../include/wx/wx.h:21:0,
from ../include/wx/wxprec.h:58:
../include/wx/hashmap.h:620:1: error: 'class wxStringEqual wxStringEqual::wxStringEqual' is inaccessible
../src/common/translation.cpp:1443:1: error: within this context
In file included from ../include/wx/wx.h:21:0,
from ../include/wx/wxprec.h:58:
../include/wx/hashmap.h: In constructor '{anonymous}::wxLocaleUntranslatedStrings::wxLocaleUntranslatedStrings(std::unordered_set<wxString, wxStringHash, wxStringEqual>::size_type, const hasher&, const key_equal&, const allocator_type&)':
../include/wx/hashmap.h:594:1: error: 'class wxStringHash wxStringHash::wxStringHash' is inaccessible
../src/common/translation.cpp:1443:1: error: within this context
In file included from ../include/wx/wx.h:21:0,
from ../include/wx/wxprec.h:58:
../include/wx/hashmap.h:620:1: error: 'class wxStringEqual wxStringEqual::wxStringEqual' is inaccessible
../src/common/translation.cpp:1443:1: error: within this context
In file included from ../include/wx/wx.h:21:0,
from ../include/wx/wxprec.h:58:
../include/wx/hashmap.h: In constructor '{anonymous}::wxLocaleUntranslatedStrings::wxLocaleUntranslatedStrings(const std::unordered_set<wxString, wxStringHash, wxStringEqual>&)':
../include/wx/hashmap.h:594:1: error: 'class wxStringHash wxStringHash::wxStringHash' is inaccessible
../src/common/translation.cpp:1443:1: error: within this context
In file included from ../include/wx/wx.h:21:0,
from ../include/wx/wxprec.h:58:
../include/wx/hashmap.h:620:1: error: 'class wxStringEqual wxStringEqual::wxStringEqual' is inaccessible
../src/common/translation.cpp:1443:1: error: within this context
Changing --std=c++11 to --std=gnu++11 does not help.
Am I doing something wrong? If not, can this be fixed?
Please note that as of GCC 4.7, it is necessary to compile wxWidgets itself
in C++11 mode if you wish to use it in a C++11 program, because GCC 4.7
introduces some ABI-incompatible library changes, so that C++03 and C++11
code cannot be linked together.
Thanks,
Nate
Vadim Zeitlin
NR> but I am getting the following errors
NR> when compiling src/common/translation.cpp:
NR>
NR> In file included from ../include/wx/wx.h:21:0,
NR> from ../include/wx/wxprec.h:58:
NR> ../include/wx/hashmap.h:594:1: error: 'class wxStringHash wxStringHash::wxStringHash' is inaccessible
NR> ../src/common/translation.cpp:1443:1: error: within this context
I don't understand why is it inaccessible nor even what exactly does "it"
refer to. Presumably there is some error inside the macros which are
supposed to deal with pre-/non-standard hash/unordered sets/maps but it'd
be really great if you could help with finding what it is.
The first step in doing would be to check which implementation is actually
being used, i.e. did configure define HAVE_STD_UNORDERED_SET as it's
supposed to do in C++ 11 mode?
NR> Please note that as of GCC 4.7, it is necessary to compile wxWidgets itself
NR> in C++11 mode if you wish to use it in a C++11 program, because GCC 4.7
NR> introduces some ABI-incompatible library changes, so that C++03 and C++11
NR> code cannot be linked together.
This is terrible news, I really hoped the bad old days of incompatible
C++ runtimes were behind us on Linux. Would you have more information about
this, i.e. why exactly did they decide to break the ABI?
Thanks,
VZ
--
TT-Solutions: wxWidgets consultancy and technical support
http://www.tt-solutions.com/
Jan van Dijk
> On Thu, 9 Feb 2012 10:06:21 +0000 Nathan Ridge <zerat...@hotmail.com>
> wrote:
>
> NR> but I am getting the following errors
> NR> when compiling src/common/translation.cpp:
> NR>
> NR> In file included from ../include/wx/wx.h:21:0,
> NR> from ../include/wx/wxprec.h:58:
> NR> ../include/wx/hashmap.h:594:1: error: 'class wxStringHash
> wxStringHash::wxStringHash' is inaccessible NR>
> ../src/common/translation.cpp:1443:1: error: within this context
>
> I don't understand why is it inaccessible nor even what exactly does "it"
> refer to. Presumably there is some error inside the macros which are
> supposed to deal with pre-/non-standard hash/unordered sets/maps but it'd
> be really great if you could help with finding what it is.
>
> The first step in doing would be to check which implementation is actually
> being used, i.e. did configure define HAVE_STD_UNORDERED_SET as it's
> supposed to do in C++ 11 mode?
FYI: Compilation works fine for me with:
$ gcc --version
gcc (GCC) 4.7.0 20111227 (experimental)
and configure flags CXXFLAGS=-std=c++0x
(And indeed, HAVE_STD_UNORDERED_MAP and HAVE_STD_UNORDERED_SET are defined in
setup.h).
> NR> Please note that as of GCC 4.7, it is necessary to compile wxWidgets
> itself NR> in C++11 mode if you wish to use it in a C++11 program, because
> GCC 4.7 NR> introduces some ABI-incompatible library changes, so that
> C++03 and C++11 NR> code cannot be linked together.
>
> This is terrible news, I really hoped the bad old days of incompatible
> C++ runtimes were behind us on Linux. Would you have more information about
> this, i.e. why exactly did they decide to break the ABI?
Maybe you find the thread that starts with:
http://gcc.gnu.org/ml/gcc/2011-10/msg00113.html
interesting.
Regards, Jan.
Vadim Zeitlin
JvD> > This is terrible news, I really hoped the bad old days of incompatible
JvD> > C++ runtimes were behind us on Linux. Would you have more information about
JvD> > this, i.e. why exactly did they decide to break the ABI?
JvD>
JvD> Maybe you find the thread that starts with:
JvD>
JvD> http://gcc.gnu.org/ml/gcc/2011-10/msg00113.html
JvD>
JvD> interesting.
Yes, it is, thanks. I guess the fact that POD layout rules have changed (I
didn't know about it to be honest and still wonder when exactly does this
apply) is a reason good enough on its own to make C++98 and C++11 code
binary incompatible. Still, I can't avoid thinking that they should have
publicized the issue more instead of just pretending that "experimental"
status justifies all the problems.
Anyhow, this is going to be a lot of fun for us too. Just when we finally
hoped to have a single ABI under Unix we're going to have 2 of them
again...
Nathan Ridge
> From: va...@wxwidgets.org
> Subject: Re: errors building wxWidgets in C++11 mode
> To: wx-u...@googlegroups.com
>
> On Thu, 9 Feb 2012 10:06:21 +0000 Nathan Ridge <zerat...@hotmail.com> wrote:
>
> NR> but I am getting the following errors
> NR> when compiling src/common/translation.cpp:
> NR>
> NR> In file included from ../include/wx/wx.h:21:0,
> NR> from ../include/wx/wxprec.h:58:
> NR> ../include/wx/hashmap.h:594:1: error: 'class wxStringHash wxStringHash::wxStringHash' is inaccessible
> NR> ../src/common/translation.cpp:1443:1: error: within this context
>
> I don't understand why is it inaccessible nor even what exactly does "it"
> refer to. Presumably there is some error inside the macros which are
> supposed to deal with pre-/non-standard hash/unordered sets/maps but it'd
> be really great if you could help with finding what it is.
>
> The first step in doing would be to check which implementation is actually
> being used, i.e. did configure define HAVE_STD_UNORDERED_SET as it's
> supposed to do in C++ 11 mode?
I will look into it.
> NR> Please note that as of GCC 4.7, it is necessary to compile wxWidgets itself
> NR> in C++11 mode if you wish to use it in a C++11 program, because GCC 4.7
> NR> introduces some ABI-incompatible library changes, so that C++03 and C++11
> NR> code cannot be linked together.
>
> This is terrible news, I really hoped the bad old days of incompatible
> C++ runtimes were behind us on Linux.
I am not thrilled about it either (wxWidgets is not the only library I've
had to rebuild, and not the only library that had problems building in C++11
mode), but I guess that is the price of an improved language.
> Would you have more information about
> this, i.e. why exactly did they decide to break the ABI?
The specific symptom I experienced when I tried to link a C++11 program
that did nothing else but create a wxFrame, to a C++03 build of wxWidgets,
is the following crash in the wxFrame constructor:
Program received signal SIGSEGV, Segmentation fault.
0x00000000006fe7c7 in __exchange_and_add (this=0xffffffffffffffe8, __a=...) at libstdc++-v3/include/ext/atomicity.h:48
48 libstdc++-v3/include/ext/atomicity.h: No such file or directory.
in libstdc++-v3/include/ext/atomicity.h
#0 0x00000000006fe7c7 in __exchange_and_add (this=0xffffffffffffffe8, __a=...) at libstdc++-v3/include/ext/atomicity.h:48
#1 __exchange_and_add_dispatch (this=0xffffffffffffffe8, __a=...) at libstdc++-v3/include/ext/atomicity.h:81
#2 std::string::_Rep::_M_dispose (this=0xffffffffffffffe8, __a=...) at libstdc++-v3/include/bits/basic_string.h:242
#3 0x00000000006ffc06 in std::string::_Rep::_M_grab (this=0xbc15a0, __str=Unhandled dwarf expression opcode 0xf3
) at libstdc++-v3/include/bits/basic_string.h:226
#4 std::string::_Rep::_M_grab (this=0xbc15a0, __str=Unhandled dwarf expression opcode 0xf3
) at libstdc++-v3/include/bits/basic_string.tcc:244
#5 std::string::assign (this=0xbc15a0, __str=Unhandled dwarf expression opcode 0xf3
) at libstdc++-v3/include/bits/basic_string.tcc:251
#6 0x0000000000425939 in wxString::operator= (this=0xbc15a0, stringSrc=...) at wxWidgets/include/wx/string.h:1920
#7 0x0000000000425f06 in wxWindowBase::SetName (this=0xbc1450, name=...) at wxWidgets/include/wx/window.h:209
#8 0x00000000004c6c6f in wxWindowBase::CreateBase (this=0xbc1450, parent=0x0, id=-1, size=..., style=541597248, name=...) at ../src/common/wincmn.cpp:390
#9 0x00000000004c6ce1 in wxWindowBase::CreateBase (this=0xbc1450, parent=0x0, id=-1, pos=..., size=..., style=541597248, validator=..., name=...) at ../src/common/wincmn.cpp:404
#10 0x0000000000431dc8 in wxTopLevelWindowGTK::Create (this=0xbc1450, parent=0x0, id=-1, title=..., pos=..., sizeOrig=..., style=541597248, name=...) at ../src/gtk/toplevel.cpp:516
#11 0x000000000044ddb9 in wxFrame::Create (this=0xbc1450, parent=0x0, id=-1, title=..., pos=..., sizeOrig=..., style=541597248, name=...) at ../src/gtk/frame.cpp:56
#12 0x00000000004269fb in wxFrame::wxFrame (this=0xbc1450, parent=0x0, id=-1, title=..., pos=..., size=..., style=541597248, name=...) at wxWidgets/include/wx/gtk/frame.h:32
#13 0x00000000004271c2 in MyFrame::MyFrame (this=0xbc1450) at test.cpp:13
#14 0x0000000000427278 in MyApp::OnInit (this=0xb461b0) at test.cpp:32
#15 0x0000000000425e1b in wxAppConsoleBase::CallOnInit (this=0xb461b0) at wxWidgets/include/wx/app.h:94
#16 0x0000000000639b37 in wxEntry (argc=@0xb16850, argv=0xb45d00) at ../src/common/init.cpp:456
#17 0x0000000000639c2c in wxEntry (argc=@0x7fffffffe13c, argv=0x7fffffffe228) at ../src/common/init.cpp:484
#18 0x000000000042547e in main (argc=1, argv=0x7fffffffe228) at test.cpp:42
The crash went away when I built the program in C++03 mode instead.
Regards,
Nate
Vadim Zeitlin
NR> > The first step in doing would be to check which implementation is actually
NR> > being used, i.e. did configure define HAVE_STD_UNORDERED_SET as it's
NR> > supposed to do in C++ 11 mode?
NR>
NR> I will look into it.
Thanks!
NR> > NR> Please note that as of GCC 4.7, it is necessary to compile wxWidgets itself
NR> > NR> in C++11 mode if you wish to use it in a C++11 program, because GCC 4.7
NR> > NR> introduces some ABI-incompatible library changes, so that C++03 and C++11
NR> > NR> code cannot be linked together.
NR> >
NR> > This is terrible news, I really hoped the bad old days of incompatible
NR> > C++ runtimes were behind us on Linux.
NR>
NR> I am not thrilled about it either (wxWidgets is not the only library I've
NR> had to rebuild, and not the only library that had problems building in C++11
NR> mode), but I guess that is the price of an improved language.
There are apparently some issues at the language level too but the one you
ran into is in the standard library and it seems like it could be avoided
by using the same std::basic_string implementation for C++98 as the new one
for C++11. Unfortunately the decision was taken not to do this, apparently.
NR> > Would you have more information about
NR> > this, i.e. why exactly did they decide to break the ABI?
NR>
NR> The specific symptom I experienced when I tried to link a C++11 program
NR> that did nothing else but create a wxFrame, to a C++03 build of wxWidgets,
NR> is the following crash in the wxFrame constructor:
This is apparently due to the use of 2 incompatible implementations of
std::basic_string...
Regards,
Nathan Ridge
> NR> I am not thrilled about it either (wxWidgets is not the only library I've
> NR> had to rebuild, and not the only library that had problems building in C++11
> NR> mode), but I guess that is the price of an improved language.
>
> There are apparently some issues at the language level too but the one you
> ran into is in the standard library and it seems like it could be avoided
> by using the same std::basic_string implementation for C++98 as the new one
> for C++11. Unfortunately the decision was taken not to do this, apparently.
My understanding is that C++11 does not permit the std::basic_string
implementation to be reference counted. GCC's C++03 std::basic_string
implementation happened to be reference counted (which was perfectly fine
according to C++03), so to say conformant they had to change it. I agree
that this is unfortunate, but I don't see what GCC could have done
differently.
Regards,
Nate
Brian Ravnsgaard Riis
Hash: SHA1
Nothing. But they should probably have removed the reference-counting
code in C++03 mode as well.
"Perfectly fine" is also a... curious statement in this regard.
CoW-optimization gets really expensive in multithreaded mode (due to
synchronization issues), but C++03 had no notion of threads...
Ah, well..
/Brian
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.12 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iQEcBAEBAgAGBQJPNIr6AAoJEKd8gmwzkHPJMBUH/30VZ8EC84fybYznbPu2RbU8
4J0rDzG8sxM0dV2K3fmKUyYD0u6Irrij7MliFrtYVDMirLSlqZZl3hUSowSmzyBV
N4o3HUa75HqL9qd2woOvN875iN1ur3/w2jGns1ZmmgxT17S4PEpga9rmpc4IJjiP
7gBRq3fBQYflnNidE9gO2xN6+xYy32/S5uWN9dzDeuiU2JHkXmhCxLwkKLf2QCtk
ahJzj/c0q28dXOVgqbp4I3+WbTcXQaqxsNXF4lDk1pf/w8JMSoVG0PWY7ETsFRbQ
wjeGGJy/QpuMu7l/VSnt6aLb5V/zBFQmJ+zzPVHBJP/4bXMqfnFLhUu1RAeQIAU=
=B6+t
-----END PGP SIGNATURE-----
Nathan Ridge
> > My understanding is that C++11 does not permit the
> > std::basic_string implementation to be reference counted. GCC's
> > C++03 std::basic_string implementation happened to be reference
> > counted (which was perfectly fine according to C++03), so to say
> > conformant they had to change it. I agree that this is unfortunate,
> > but I don't see what GCC could have done differently.
>
> Nothing. But they should probably have removed the reference-counting
> code in C++03 mode as well.
Then they would have an ABI incompatibility between C++03 code
compiled with an older GCC (e.g. 4.6 or before) and a newer GCC
(e.g. 4.7 or later). That seems even worse.
> "Perfectly fine" is also a... curious statement in this regard.
> CoW-optimization gets really expensive in multithreaded mode (due to
> synchronization issues), but C++03 had no notion of threads...
All I meant was that their implementation was conformant to C++03.
Regards,
Nate
Nathan Ridge
> From: va...@wxwidgets.org
>
> NR> but I am getting the following errors
> NR> when compiling src/common/translation.cpp:
> NR>
> NR> In file included from ../include/wx/wx.h:21:0,
> NR> from ../include/wx/wxprec.h:58:
> NR> ../include/wx/hashmap.h:594:1: error: 'class wxStringHash wxStringHash::wxStringHash' is inaccessible
> NR> ../src/common/translation.cpp:1443:1: error: within this context
>
> I don't understand why is it inaccessible nor even what exactly does "it"
> refer to. Presumably there is some error inside the macros which are
> supposed to deal with pre-/non-standard hash/unordered sets/maps but it'd
> be really great if you could help with finding what it is.
>
> The first step in doing would be to check which implementation is actually
> being used, i.e. did configure define HAVE_STD_UNORDERED_SET as it's
> supposed to do in C++ 11 mode?
Yes it did. The expansion of the WX_DECLARE_HASH_SET macro call is as follows:
class wxLocaleUntranslatedStrings \
: public std::unordered_set< wxString, wxStringHash, wxStringEqual > \
{ \
public: \
explicit wxLocaleUntranslatedStrings(size_type n = 3, \
const hasher& h = hasher(), \
const key_equal& ke = key_equal(), \
const allocator_type& a = allocator_type()) \
: std::unordered_set< wxString, wxStringHash, wxStringEqual >(n, h, ke, a) \
{} \
template <class InputIterator> \
wxLocaleUntranslatedStrings(InputIterator f, InputIterator l, \
const hasher& h = hasher(), \
const key_equal& ke = key_equal(), \
const allocator_type& a = allocator_type()) \
: std::unordered_set< wxString, wxStringHash, wxStringEqual >(f, l, h, ke, a)\
{} \
wxLocaleUntranslatedStrings(const std::unordered_set< wxString, wxStringHash, wxStringEqual >& s) \
: std::unordered_set< wxString, wxStringHash, wxStringEqual >(s) \
{} \
};
There are errors pointing to each of the constructors, saying
'class wxStringHash wxStringHash::wxStringHash' is inaccessible
and
'class wxStringEqual wxStringEqual::wxStringEqual' is inaccessible
I agree with you that it is not clear what exactly is not accessible...
Regards,
Nate
Nathan Ridge
> From: zerat...@hotmail.com
So after a fair bit of debugging, and with some help [1], I figured it out.
The GCC 4.7 implementation of std::unordered_set indirectly inherits
privately from its Hash and Equal template arguments, for purposes of
empty base optimization.
That means that in the code above, wxStringHash and wxStringEqual are
indirect private base classes of wxLocaleUntranslatedStrings. Now it seems
that a reference to a base class name in a constructor is interpreted as a
reference to the base class's *constructor*, which is this case is
inaccessible because the base class is private. This can be illustrated
by the following snippet:
struct B
{
};
struct A : private B
{
};
struct C : public A
{
C(B);
};
which fails to compile with a similar error.
To tell the compiler that we are talking about the base class's name,
rather than its constructor, we need to fully qualify the base class name,
as follows:
struct B
{
};
struct A : private B
{
};
struct C : public A
{
C(::B); // note the "::"
};
Now this compiles.
So, the solution is to replace
WX_DECLARE_HASH_SET(wxString, wxStringHash, wxStringEqual,
wxLocaleUntranslatedStrings);
with
WX_DECLARE_HASH_SET(wxString, ::wxStringHash, ::wxStringEqual,
wxLocaleUntranslatedStrings);
and all is well.
I'd prepare a patch but for 4 characters it's probably not worth it...
Regards,
Nate
[1] http://stackoverflow.com/questions/9223153/c-compiler-error-involving-private-inheritance
Nathan Ridge
> From: zerat...@hotmail.com
>
> So, the solution is to replace
>
> WX_DECLARE_HASH_SET(wxString, wxStringHash, wxStringEqual,
> wxLocaleUntranslatedStrings);
>
> with
>
> WX_DECLARE_HASH_SET(wxString, ::wxStringHash, ::wxStringEqual,
> wxLocaleUntranslatedStrings);
>
> and all is well.
>
> I'd prepare a patch but for 4 characters it's probably not worth it...
There are a few other places in wxWidgets that suffer from the same
problem, so I prepared a patch after all (attached).
I am happy to report that which this patch, wxWidgets compiles
successfully in C++11 mode with a recent build of GCC 4.7, and
my C++11 program runs fine after linking to this version.
Regards,
Nate
Vadim Zeitlin
NR> > > My understanding is that C++11 does not permit the
NR> > > std::basic_string implementation to be reference counted. GCC's
NR> > > C++03 std::basic_string implementation happened to be reference
NR> > > counted (which was perfectly fine according to C++03), so to say
NR> > > conformant they had to change it. I agree that this is unfortunate,
NR> > > but I don't see what GCC could have done differently.
NR> >
NR> > Nothing. But they should probably have removed the reference-counting
NR> > code in C++03 mode as well.
Exactly.
NR> Then they would have an ABI incompatibility between C++03 code
NR> compiled with an older GCC (e.g. 4.6 or before) and a newer GCC
NR> (e.g. 4.7 or later). That seems even worse.
No, they could just have a new version of standard library.
Anyhow, for me the killer argument remains the POD layout change. I still
don't know what exactly it is but if PODs can be laid out incompatibly in
C++98 and C++11 then it's really impossible to blame gcc folks for doing
what they did (although, again, they should have really made this more
explicit). But at this stage I can't help wondering what possible reason
could the Standards Committee have had to make such change.
I'd be curious to know more about this if anybody has more information.
Thanks,
Vadim Zeitlin
NR> > So, the solution is to replace
NR> >
NR> > WX_DECLARE_HASH_SET(wxString, wxStringHash, wxStringEqual,
NR> > wxLocaleUntranslatedStrings);
NR> >
NR> > with
NR> >
NR> > WX_DECLARE_HASH_SET(wxString, ::wxStringHash, ::wxStringEqual,
NR> > wxLocaleUntranslatedStrings);
NR> >
NR> > and all is well.
NR> >
NR> > I'd prepare a patch but for 4 characters it's probably not worth it...
NR>
NR> There are a few other places in wxWidgets that suffer from the same
NR> problem, so I prepared a patch after all (attached).
Thanks, applied as r70556. I'm not totally happy about it as I'd prefer
to change something in the macros themselves to make the code using them
continue working in C++11 mode but I can't think of any way to do this
(prepending "::" isn't going to work as this could break existing code
using these macros with hashers/comparators declared in current non global
namespace). But it's definitely better than failing to compile at all so
let's use this for now.
NR> I am happy to report that which this patch, wxWidgets compiles
NR> successfully in C++11 mode with a recent build of GCC 4.7, and
NR> my C++11 program runs fine after linking to this version.
Great to hear! Please consider updating
http://wiki.wxwidgets.org/Supported_Platforms with this information.
Thanks again,
Nathan Ridge
> NR> > > My understanding is that C++11 does not permit the
> NR> > > std::basic_string implementation to be reference counted. GCC's
> NR> > > C++03 std::basic_string implementation happened to be reference
> NR> > > counted (which was perfectly fine according to C++03), so to say
> NR> > > conformant they had to change it. I agree that this is unfortunate,
> NR> > > but I don't see what GCC could have done differently.
> NR> >
> NR> > Nothing. But they should probably have removed the reference-counting
> NR> > code in C++03 mode as well.
>
> Exactly.
>
> NR> Then they would have an ABI incompatibility between C++03 code
> NR> compiled with an older GCC (e.g. 4.6 or before) and a newer GCC
> NR> (e.g. 4.7 or later). That seems even worse.
>
> No, they could just have a new version of standard library.
Maybe I'm not understanding what you have in mind, but I don't see how that helps.
People wanting to use C++11 would still have to rebuild wxWidgets using the new
version of the standard library, right?
> Anyhow, for me the killer argument remains the POD layout change. I still
> don't know what exactly it is but if PODs can be laid out incompatibly in
> C++98 and C++11 then it's really impossible to blame gcc folks for doing
> what they did (although, again, they should have really made this more
> explicit). But at this stage I can't help wondering what possible reason
> could the Standards Committee have had to make such change.
>
> I'd be curious to know more about this if anybody has more information.
I don't know much about this, and I'd be curious to know more as well.
Regards,
Nate
Nathan Ridge
> NR> > So, the solution is to replace
> NR> >
> NR> > WX_DECLARE_HASH_SET(wxString, wxStringHash, wxStringEqual,
> NR> > wxLocaleUntranslatedStrings);
> NR> >
> NR> > with
> NR> >
> NR> > WX_DECLARE_HASH_SET(wxString, ::wxStringHash, ::wxStringEqual,
> NR> > wxLocaleUntranslatedStrings);
> NR> >
> NR> > and all is well.
> NR> >
> NR> > I'd prepare a patch but for 4 characters it's probably not worth it...
> NR>
> NR> There are a few other places in wxWidgets that suffer from the same
> NR> problem, so I prepared a patch after all (attached).
>
> Thanks, applied as r70556. I'm not totally happy about it as I'd prefer
> to change something in the macros themselves to make the code using them
> continue working in C++11 mode but I can't think of any way to do this
> (prepending "::" isn't going to work as this could break existing code
> using these macros with hashers/comparators declared in current non global
> namespace). But it's definitely better than failing to compile at all so
> let's use this for now.
Someone on SO helpfully pointed out that prepending "struct" instead of "::"
to the typename fixes the problem as well. That should work for types in any
namespace, so it could be done by the macro.
> NR> I am happy to report that which this patch, wxWidgets compiles
> NR> successfully in C++11 mode with a recent build of GCC 4.7, and
> NR> my C++11 program runs fine after linking to this version.
>
> Great to hear! Please consider updating
> http://wiki.wxwidgets.org/Supported_Platforms with this information.
I updated the wxGTK-->Linux section with an entry for GCC 4.7.
I notice that the previous entries only go up to GCC 4.1. I have definitely
used wxWidgets successfully on Linux with intervening GCC versions
(specifically, 4.4, 4.5, and 4.6), but I don't remember which revisions,
or even whether it was 2.8.x or 2.9.x. Should I mention it nonetheless?
Regards,
Nate
Vadim Zeitlin
NR> > NR> Then they would have an ABI incompatibility between C++03 code
NR> > NR> compiled with an older GCC (e.g. 4.6 or before) and a newer GCC
NR> > NR> (e.g. 4.7 or later). That seems even worse.
NR> >
NR> > No, they could just have a new version of standard library.
NR>
NR> Maybe I'm not understanding what you have in mind, but I don't see how that helps.
NR> People wanting to use C++11 would still have to rebuild wxWidgets using the new
NR> version of the standard library, right?
Yes, but we could have the same version of wxWidgets (linked to the new
standard library) for both the programs compiled in C++ 98 and C++ 11
modes. As it is right now, you're going to have 2 versions of wxWidgets
unless you're prepared to recompile everything, including any other C++
libraries you use, in C++ 11.
NR> > Thanks, applied as r70556. I'm not totally happy about it as I'd prefer
NR> > to change something in the macros themselves to make the code using them
NR> > continue working in C++11 mode but I can't think of any way to do this
NR> > (prepending "::" isn't going to work as this could break existing code
NR> > using these macros with hashers/comparators declared in current non global
NR> > namespace). But it's definitely better than failing to compile at all so
NR> > let's use this for now.
NR>
NR> Someone on SO helpfully pointed out that prepending "struct" instead of "::"
NR> to the typename fixes the problem as well. That should work for types in any
NR> namespace, so it could be done by the macro.
Unfortunately I expect this to result in warnings from MSVC if you declare
a custom hasher or comparator using "class" as this compiler thinks that if
you used struct in one place, you shouldn't be using class in another one
and vice versa (and I can't really blame it, there doesn't seem to be any
good reason to do this in normal code).
NR> I updated the wxGTK-->Linux section with an entry for GCC 4.7.
Thanks!
NR> I notice that the previous entries only go up to GCC 4.1. I have definitely
NR> used wxWidgets successfully on Linux with intervening GCC versions
NR> (specifically, 4.4, 4.5, and 4.6), but I don't remember which revisions,
NR> or even whether it was 2.8.x or 2.9.x. Should I mention it nonetheless?
Yes, I think we should mention that all these compilers work too, although
perhaps not by adding a new line for each of them but just having a single
one for "4.[456]". We could also put "2.9.3" in the version column as I'm
pretty sure it built with all of them.
Regards,
Nathan Ridge
> From: va...@wxwidgets.org
>
> On Fri, 10 Feb 2012 20:04:44 +0000 Nathan Ridge <zerat...@hotmail.com> wrote:
>
> NR> > NR> Then they would have an ABI incompatibility between C++03 code
> NR> > NR> compiled with an older GCC (e.g. 4.6 or before) and a newer GCC
> NR> > NR> (e.g. 4.7 or later). That seems even worse.
> NR> >
> NR> > No, they could just have a new version of standard library.
> NR>
> NR> Maybe I'm not understanding what you have in mind, but I don't see how that helps.
> NR> People wanting to use C++11 would still have to rebuild wxWidgets using the new
> NR> version of the standard library, right?
>
> Yes, but we could have the same version of wxWidgets (linked to the new
> standard library) for both the programs compiled in C++ 98 and C++ 11
> modes. As it is right now, you're going to have 2 versions of wxWidgets
> unless you're prepared to recompile everything, including any other C++
> libraries you use, in C++ 11.
OK, I see your point now.
I guess GCC is not doing this because it would be extra work to maintain a
C++98-compatible version of the new library (presumably the new implementation
makes use of C++11 features). If you feel strongly about it, you could request
that such a version be created/maintained.
> NR> > Thanks, applied as r70556. I'm not totally happy about it as I'd prefer
> NR> > to change something in the macros themselves to make the code using them
> NR> > continue working in C++11 mode but I can't think of any way to do this
> NR> > (prepending "::" isn't going to work as this could break existing code
> NR> > using these macros with hashers/comparators declared in current non global
> NR> > namespace). But it's definitely better than failing to compile at all so
> NR> > let's use this for now.
> NR>
> NR> Someone on SO helpfully pointed out that prepending "struct" instead of "::"
> NR> to the typename fixes the problem as well. That should work for types in any
> NR> namespace, so it could be done by the macro.
>
> Unfortunately I expect this to result in warnings from MSVC if you declare
> a custom hasher or comparator using "class" as this compiler thinks that if
> you used struct in one place, you shouldn't be using class in another one
> and vice versa (and I can't really blame it, there doesn't seem to be any
> good reason to do this in normal code).
I see. I guess the only thing that can be done then is document the macro
as requiring fully qualified type names. (Additionally, one could have the
macro insert the "struct" on non-MSVC platforms).
> NR> I notice that the previous entries only go up to GCC 4.1. I have definitely
> NR> used wxWidgets successfully on Linux with intervening GCC versions
> NR> (specifically, 4.4, 4.5, and 4.6), but I don't remember which revisions,
> NR> or even whether it was 2.8.x or 2.9.x. Should I mention it nonetheless?
>
> Yes, I think we should mention that all these compilers work too, although
> perhaps not by adding a new line for each of them but just having a single
> one for "4.[456]". We could also put "2.9.3" in the version column as I'm
> pretty sure it built with all of them.
Done. I also added an entry for Win32/x86/g++ 4.6.1.
Regards,
Nate
Alec Ross
<zerat...@hotmail.com> writes
>
>> From: va...@wxwidgets.org
>>
>> On Fri, 10 Feb 2012 20:04:44 +0000 Nathan Ridge
>><zerat...@hotmail.com> wrote:
>>
>> NR> > NR> Then they would have an ABI incompatibility between C++03 code
>> NR> > NR> compiled with an older GCC (e.g. 4.6 or before) and a newer GCC
>> NR> > NR> (e.g. 4.7 or later). That seems even worse.
>> NR> >
>> NR> > No, they could just have a new version of standard library.
>> NR>
>> NR> Maybe I'm not understanding what you have in mind, but I don't
>> NR> People wanting to use C++11 would still have to rebuild wxWidgets
>> NR> version of the standard library, right?
>>
>> Yes, but we could have the same version of wxWidgets (linked to the new
>> standard library) for both the programs compiled in C++ 98 and C++ 11
>> modes. As it is right now, you're going to have 2 versions of wxWidgets
>> unless you're prepared to recompile everything, including any other C++
>> libraries you use, in C++ 11.
>
>OK, I see your point now.
>
>I guess GCC is not doing this because it would be extra work to maintain a
>C++98-compatible version of the new library (presumably the new implementation
>makes use of C++11 features). If you feel strongly about it, you could request
>that such a version be created/maintained.
>
>> NR> > Thanks, applied as r70556. I'm not totally happy about it as I'd prefer
>> NR> > to change something in the macros themselves to make the code
>> NR> > continue working in C++11 mode but I can't think of any way to do this
>> NR> > (prepending "::" isn't going to work as this could break existing code
>> NR> > using these macros with hashers/comparators declared in current
>> NR> > namespace). But it's definitely better than failing to compile
>> NR> > let's use this for now.
>> NR>
>> NR> Someone on SO helpfully pointed out that prepending "struct"
>> NR> to the typename fixes the problem as well. That should work for
>> NR> namespace, so it could be done by the macro.
>>
>> Unfortunately I expect this to result in warnings from MSVC if you declare
>> a custom hasher or comparator using "class" as this compiler thinks that if
>> you used struct in one place, you shouldn't be using class in another one
>> and vice versa (and I can't really blame it, there doesn't seem to be any
>> good reason to do this in normal code).
>
>I see. I guess the only thing that can be done then is document the macro
>as requiring fully qualified type names. (Additionally, one could have the
>macro insert the "struct" on non-MSVC platforms).
>
Well this might well work. But ... I suspect that there is little or no
gtee of object layout being identical for structs and classes w/
identical, or effectively identical, contents. And fundamentally there
is probably an ODR violation here. No?
Would it be reasonable to simply change the class to struct here?
>> NR> I notice that the previous entries only go up to GCC 4.1. I have
>> NR>definitely
>> NR> used wxWidgets successfully on Linux with intervening GCC versions
>> NR> (specifically, 4.4, 4.5, and 4.6), but I don't remember which revisions,
>> NR> or even whether it was 2.8.x or 2.9.x. Should I mention it nonetheless?
>>
>> Yes, I think we should mention that all these compilers work too, although
>> perhaps not by adding a new line for each of them but just having a single
>> one for "4.[456]". We could also put "2.9.3" in the version column as I'm
>> pretty sure it built with all of them.
>
>Done. I also added an entry for Win32/x86/g++ 4.6.1.
>
>Regards,
>Nate
>
>
--
Alec Ross
Nathan Ridge
> To: wx-u...@googlegroups.com
> Subject: RE: errors building wxWidgets in C++11 mode
> Date: Fri, 10 Feb 2012 07:01:52 +0000
Vadim Zeitlin
NR> The tests for wxHashSet also require a patch, attached.
Thanks, but returning to a previous message in this thread
(http://thread.gmane.org/gmane.comp.lib.wxwidgets.general/75475/focus=75502)
I wonder if we shouldn't try adding "struct " into the macros themselves.
As you pointed out, this could be done safely for non-MSVC compilers and
I'm willing to bet that MSVC will implement some workaround to avoid
breaking the existing code and so won't need this anyhow.
Would it be possible for you to test whether this works, i.e. if the tests
build after this change and if r70556 can be reverted?
TIA,
Nathan Ridge
> NR> The tests for wxHashSet also require a patch, attached.
>
> Thanks, but returning to a previous message in this thread
> As you pointed out, this could be done safely for non-MSVC compilers and
> I'm willing to bet that MSVC will implement some workaround to avoid
> breaking the existing code and so won't need this anyhow.
>
> Would it be possible for you to test whether this works, i.e. if the tests
While trying to build the latest trunk with those changes, I
came across the following errors:
In file included from ../include/wx/msw/webview_ie.h:9::,,
from ../src/msw/webview_ie.cpp:7::
../include/wx/msw/ole/automtn.h:12:::: error: 'LCID' does not name a type
../include/wx/msw/ole/automtn.h:16::8:: error: 'LCID' has not been declared
../include/wx/msw/ole/automtn.h:22:::: error: 'LCID' does not name a type
What might be causing this?
Thanks,
Nate
Nathan Ridge
header that defines LCID does not get included until *after* ole/automtn.h.
Regards,
Nate
Vadim Zeitlin
NR> > In file included from ../include/wx/msw/webview_ie.h:9::,,
NR> > from ../src/msw/webview_ie.cpp:7::
NR> > ../include/wx/msw/ole/automtn.h:12:::: error: 'LCID' does not name a type
NR> > ../include/wx/msw/ole/automtn.h:16::8:: error: 'LCID' has not been declared
NR> > ../include/wx/msw/ole/automtn.h:22:::: error: 'LCID' does not name a type
NR> >
NR> > What might be causing this?
NR>
NR> Looking at the preprocessed source of that file, it seems that the windows
NR> header that defines LCID does not get included until after ole/automtn.h.
Yes, I think I fixed this in r72296, could you please retry?
Thanks,
Nathan Ridge
> NR> The tests for wxHashSet also require a patch, attached.
>
> Thanks, but returning to a previous message in this thread
> (http://thread.gmane.org/gmane.comp.lib.wxwidgets.general/75475/focus=75502)
> I wonder if we shouldn't try adding "struct " into the macros themselves.
> As you pointed out, this could be done safely for non-MSVC compilers and
> I'm willing to bet that MSVC will implement some workaround to avoid
> breaking the existing code and so won't need this anyhow.
>
> Would it be possible for you to test whether this works, i.e. if the tests
> build after this change and if r70556 can be reverted?
inject the keyword 'struct' before the names of the hasher and comparator
classes on all platforms except MSVC.
Both the library itself and the tests compile successfully with these
changes with GCC 4.7 in C++11 mode.
Regards,
Nate
Vadim Zeitlin
NR> Attached is a patch that reverts r70556 and modifies _WX_DECLARE_HASH_SET to
NR> inject the keyword 'struct' before the names of the hasher and comparator
NR> classes on all platforms except MSVC.
NR>
NR> Both the library itself and the tests compile successfully with these
NR> changes with GCC 4.7 in C++11 mode.
Great, applied as r72297, thanks!
Sam Hu
../../src/stc/scintilla/lexers/LexAda.cxx:529:20: error: 'isascii' was not declared in this scope
mingw32-make: *** [gcc_mswu\wxscintilla_LexAda.o] Error 1
Sam
On Thursday, February 9, 2012 6:06:21 PM UTC+8, Nathan Ridge wrote:
Hello,I am trying to build wxWidgets with GCC in C++11 mode (that is, by passing
CXXFLAGS=--std=c++11 to configure), but I am getting the following errors
when compiling src/common/translation.cpp:
In file included from ../include/wx/wx.h:21:0,
from ../include/wx/wxprec.h:58:
../include/wx/hashmap.h:594:1: error: 'class wxStringHash wxStringHash::wxStringHash' is inaccessible
../src/common/translation.cpp:1443:1: error: within this context
In file included from ../include/wx/wx.h:21:0,
from ../include/wx/wxprec.h:58:
../include/wx/hashmap.h:620:1: error: 'class wxStringEqual wxStringEqual::wxStringEqual' is inaccessible
../src/common/translation.cpp:1443:1: error: within this context
In file included from ../include/wx/wx.h:21:0,
from ../include/wx/wxprec.h:58:
../include/wx/hashmap.h: In constructor '{anonymous}::wxLocaleUntranslatedStrings::wxLocaleUntranslatedStrings(std::unordered_set<wxString, wxStringHash, wxStringEqual>::size_type, const hasher&, const key_equal&, const allocator_type&)':
../include/wx/hashmap.h:594:1: error: 'class wxStringHash wxStringHash::wxStringHash' is inaccessible
../src/common/translation.cpp:1443:1: error: within this context
In file included from ../include/wx/wx.h:21:0,
from ../include/wx/wxprec.h:58:
../include/wx/hashmap.h:620:1: error: 'class wxStringEqual wxStringEqual::wxStringEqual' is inaccessible
../src/common/translation.cpp:1443:1: error: within this context
In file included from ../include/wx/wx.h:21:0,
from ../include/wx/wxprec.h:58:
../include/wx/hashmap.h: In constructor '{anonymous}::wxLocaleUntranslatedStrings::wxLocaleUntranslatedStrings(const std::unordered_set<wxString, wxStringHash, wxStringEqual>&)':
../include/wx/hashmap.h:594:1: error: 'class wxStringHash wxStringHash::wxStringHash' is inaccessible
../src/common/translation.cpp:1443:1: error: within this context
In file included from ../include/wx/wx.h:21:0,
from ../include/wx/wxprec.h:58:
../include/wx/hashmap.h:620:1: error: 'class wxStringEqual wxStringEqual::wxStringEqual' is inaccessible
../src/common/translation.cpp:1443:1: error: within this context
Changing --std=c++11 to --std=gnu++11 does not help.
Am I doing something wrong? If not, can this be fixed?
Please note that as of GCC 4.7, it is necessary to compile wxWidgets itself
in C++11 mode if you wish to use it in a C++11 program, because GCC 4.7
introduces some ABI-incompatible library changes, so that C++03 and C++11
code cannot be linked together.
Thanks,
Nate
Nathan Ridge
> Sorry for my stepping in,but I am running into similar issues...
> Platform: win 7
> MinGW gcc:4.7.1 from [url]http://nuwen.net/mingw.html[/url]
> wx Daily snapshot: Sep 19,downloaded wx...4801d96.zip
> compiled command:
> set PATH=...
> mingw32-make -f makefile.gcc BUILD=release SHARED=0 MONOLITHIC=1
> UNICODE=1 CXXFLAGS=--std=c++11 2>errlog.txt
>
> error message:
> ../../src/stc/scintilla/lexers/LexAda.cxx: In function 'bool
> IsWordStartCharacter(int)':
> ../../src/stc/scintilla/lexers/LexAda.cxx:529:20: error: 'isascii' was
> not declared in this scope
> mingw32-make: *** [gcc_mswu\wxscintilla_LexAda.o] Error 1
> Help and guidline for working wx with c++11 or c++0x with MinGW under
> Windows would be much appreicated.
(By the way, this reliance on GNU extensions should be fixed on the
wx side, right?)
Regards,
Nate
Vadim Zeitlin
NR> > error message:
NR> > ../../src/stc/scintilla/lexers/LexAda.cxx: In function 'bool
NR> > IsWordStartCharacter(int)':
NR> > ../../src/stc/scintilla/lexers/LexAda.cxx:529:20: error: 'isascii' was
NR> > not declared in this scope
NR> > mingw32-make: *** [gcc_mswu\wxscintilla_LexAda.o] Error 1
NR> > Help and guidline for working wx with c++11 or c++0x with MinGW under
NR> > Windows would be much appreicated.
NR>
NR> Try compiling with --std=gnu++11 rather than --std=c++11.
NR>
NR> (By the way, this reliance on GNU extensions should be fixed on the
NR> wx side, right?)
Yes, but the trouble is that this use of isascii() is in 3rd party code.
Ideal would be to change Scintilla itself to avoid it.
Regards,