Summary: | games-strategy/wesnoth-1.8.* fails to build with dev-libs/boost-1.47.0-r1 with gcc 4.6 | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Ben Longbons <b.r.longbons> |
Component: | [OLD] Games | Assignee: | Gentoo Games <games> |
Status: | RESOLVED INVALID | ||
Severity: | normal | CC: | gentoo, steffen |
Priority: | Normal | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Bug Depends on: | |||
Bug Blocks: | 378697 | ||
Attachments: |
wesnoth 1.8.6 build.log
backported patch from upstream add the patch line to the ebuild |
Description
Ben Longbons
2011-10-30 17:01:31 UTC
Created attachment 291249 [details]
wesnoth 1.8.6 build.log
builds fine for me with dev-libs/boost-1.47.0-r1 on stable x86. Hm, it it is related to an added boost check for GCC 4.6. I don't understand why boost would have made this change - GCC 4.6 supports range-based for natively, but it doesn't try to use that for BOOST_FOREACH I don't pretend to understand most of the header, but I changed the condition and wesnoth built properly. --- in /usr/include/boost-1_46/boost/foreach.hpp : // Some compilers let us detect even const-qualified rvalues at compile-time #if BOOST_WORKAROUND(BOOST_MSVC, >= 1310) && !defined(_PREFAST_) \ || (BOOST_WORKAROUND(__GNUC__, >= 4) && !defined(BOOST_INTEL) && !defined(BOOST_CLANG)) \ || (BOOST_WORKAROUND(__GNUC__, == 3) && (__GNUC_MINOR__ >= 4) && !defined(BOOST_INTEL) && \ !defined(BOOST_CLANG)) # define BOOST_FOREACH_COMPILE_TIME_CONST_RVALUE_DETECTION #else --- in /usr/include/boost-1_47/boost/foreach.hpp : // Some compilers let us detect even const-qualified rvalues at compile-time #if !defined(BOOST_NO_RVALUE_REFERENCES) \ || BOOST_WORKAROUND(BOOST_MSVC, >= 1310) && !defined(_PREFAST_) \ || (BOOST_WORKAROUND(__GNUC__, == 4) && (__GNUC_MINOR__ <= 5) && !defined(BOOST_INTEL) && \ !defined(BOOST_CLANG)) \ || (BOOST_WORKAROUND(__GNUC__, == 3) && (__GNUC_MINOR__ >= 4) && !defined(BOOST_INTEL) && \ !defined(BOOST_CLANG)) # define BOOST_FOREACH_COMPILE_TIME_CONST_RVALUE_DETECTION #else See: https://svn.boost.org/trac/boost/ticket/5279 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49021 Also, as someone in #boost helpfully pointed out - the fact that GCC 4.6 supports range-based for is irrelevant because not everybody uses C++11 - and to remember to file a bug on Boost's tracker. so it's a gcc bug. and hey, you're using a masked gcc version so you get to keep both pieces. Sure, GCC 4.6 is masked *now*, but it (or possibly a later version) will be unmasked *sometime*. It is a *fix* in GCC 4.6 that was *incorrect* in previous versions, which uncovered a *bug* in boost (which may be very difficult to fix). What is the point in "masked for testing" if we can't file bug reports about broken packages? From my understanding, with GCC 4.6: certain code (not necessarily what is in wesnoth) will fail at runtime with older versions of boost, and certain code (such as in wesnoth) will fail to compile with newer versions of boost. Also, why is the wesnoth ebuild unconditionally overriding the version chosen by eselect boost? Shouldn't it only do that if eselect boost points to something older than the required version? This seems to be fixed upstream with Wesnoth. See https://gna.org/bugs/index.php?18399 So it seems we only have to wait for next Wesnoth release. Created attachment 292585 [details, diff]
backported patch from upstream
Although upstream has decided not to fix for 1.8, the patch cleanly applies after removing the changelog section.
Created attachment 292587 [details, diff]
add the patch line to the ebuild
(In reply to comment #5) > so it's a gcc bug. and hey, you're using a masked gcc version so you get to > keep both pieces. I can confirm Ben's backport works on my mostly ~amd64 system. As a patch has now been located and adapted, please include it so gcc-4.6 can move one bit closer to ~arch :) |