GCC 4.6.x + Boost.Signals == failure
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Who is the Boost.Signals maintainer? Boost.Signals fails to build against a stage-3 GCC build (GCC 4.6.x, r169444) due to an ambigious call to the erase method of a std::map<>. Do we have a GCC 4.6.x tester? This compiler is in the Debian- and Ubuntu- distribution these days. According to the regressions page, we don't appear to have a GCC 4.6.x tester... this would be nice to have. - -- Bryce Lelbach aka wash boost-spirit.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) iEYEARECAAYFAk1M4qUACgkQ9cB/V3/s9EwaGACeLl0j1IqPnrifdouCW1IfLGAC MqoAn2Z8IrxozFNbvwpNsS/HSr0XUD4f =JTd2 -----END PGP SIGNATURE-----
Bryce Lelbach aka wash wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Who is the Boost.Signals maintainer? Boost.Signals fails to build against a stage-3 GCC build (GCC 4.6.x, r169444) due to an ambigious call to the erase method of a std::map<>.
Do we have a GCC 4.6.x tester? This compiler is in the Debian- and Ubuntu- distribution these days. According to the regressions page, we don't appear to have a GCC 4.6.x tester... this would be nice to have.
We have Win7-x64 jc-bell.com who is testing gcc-mingw-4.6.0 on trunk. BTW, no errors for Boost.Signal in last report rev 68358. Which version of Boost.Signals fails? Vicente -- View this message in context: http://boost.2283326.n4.nabble.com/GCC-4-6-x-Boost-Signals-failure-tp3261517... Sent from the Boost - Dev mailing list archive at Nabble.com.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Sat, 5 Feb 2011 01:20:39 -0800 (PST) Vicente Botet <vicente.botet@wanadoo.fr> wrote:
BTW, no errors for Boost.Signal in last report rev 68358.
Right. No errors, because there is no tester for the broken environment :)
Which version of Boost.Signals fails?
The last change on the broken file in question was about a year ago. So, I'd say any version from about a year ago till now compiled against recentish built GCC 4.6.x Find attached a patch for this bug. The problem: GNU stdlib failure or GNU stdlib failure compounded by GCC failure. Passing a parameter of type std::map<>::iterator to std::map<>::erase() is ambigious for silly reasons. Definitions for std::map<>::erase() in the GNU stdlib are provided for std::map<>::key_type const& and std::map<>::const_iterator, if c++0x support is enabled (which apparently seems to be just the "default" state of GCC these days). If c++0x support is disabled, the working C++99 std::map<>::erase() which takes an std::map<>::iterator is enabled (in C++0x, erase()'s return type changes from void to iterator). - -- Bryce Lelbach aka wash boost-spirit.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) iEYEARECAAYFAk1PPWcACgkQ9cB/V3/s9ExnGgCfXYMObT6yV81CHgSP/J6H4ihi YXsAnR5PuaWGIAZc4djdzdmnmk7IlXFZ =VVGr -----END PGP SIGNATURE-----
AMDG On 2/6/2011 4:31 PM, Bryce Lelbach (wash) wrote:
On Sat, 5 Feb 2011 01:20:39 -0800 (PST) Vicente Botet<vicente.botet@wanadoo.fr> wrote:
BTW, no errors for Boost.Signal in last report rev 68358.
Right. No errors, because there is no tester for the broken environment :)
Which version of Boost.Signals fails?
The last change on the broken file in question was about a year ago. So, I'd say any version from about a year ago till now compiled against recentish built GCC 4.6.x
Find attached a patch for this bug. The problem: GNU stdlib failure or GNU stdlib failure compounded by GCC failure. Passing a parameter of type std::map<>::iterator to std::map<>::erase() is ambigious for silly reasons. Definitions for std::map<>::erase() in the GNU stdlib are provided for std::map<>::key_type const& and std::map<>::const_iterator, if c++0x support is enabled (which apparently seems to be just the "default" state of GCC these days). If c++0x support is disabled, the working C++99 std::map<>::erase() which takes an std::map<>::iterator is enabled (in C++0x, erase()'s return type changes from void to iterator).
a) Please check defined(__GNUC__) first to avoid warnings b) __GNUC__ >= 4 && __GNUC_MINOR__ >= 6 is a little silly, since it will be false for gcc 5.0. c) Will the patch work when C++0x support is disabled? In Christ, Steven Watanabe
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Sun, 06 Feb 2011 17:07:34 -0800 Steven Watanabe <watanabesj@gmail.com> wrote:
a) Please check defined(__GNUC__) first to avoid warnings
K
b) __GNUC__ >= 4 && __GNUC_MINOR__ >= 6 is a little silly, since it will be false for gcc 5.0.
Good point
c) Will the patch work when C++0x support is disabled?
No, should probably check for the G++ detection macro as well. - -- Bryce Lelbach aka wash boost-spirit.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) iEYEARECAAYFAk1PRx0ACgkQ9cB/V3/s9EwBKACdHgRB3bnEeyZwkkzSNMMPxNVW mW8AnjIJ1YseDCvHpuogbIETw+B7JfZR =I5H4 -----END PGP SIGNATURE-----
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Turns out that this behavior is not a GCC bug, a change in the definition of erase is in fact mandated in C++0x. Better solution is needed here - GCC people suggested one which I have yet to try.. - -- Bryce Lelbach aka wash boost-spirit.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) iEYEARECAAYFAk1QtK8ACgkQ9cB/V3/s9ExYogCdFA6FvpE/XO/4JWxAUKqCcZ83 jJwAn2aQvT74kFeLTSnL1DGUS0mVBphI =SfqE -----END PGP SIGNATURE-----
participants (3)
-
Bryce Lelbach -
Steven Watanabe -
Vicente Botet