Please add boost 1.54.0 to the portage tree. Reproducible: Always
benefits of a bump are listed here: http://www.boost.org/users/history/version_1_54_0.html
Created attachment 352602 [details, diff] boost-build-1.54.0-fix-test.patch
Created attachment 352604 [details, diff] boost-build-1.54.0-support_dots_in_python-buildid.patch adjusted patches for boost-build
I got several: error: ‘uintptr_t’ was not declared in this scope during the build. Fixed by including <stdint.h> in: ./boost/log/detail/intptr_t.hpp ./boost/atomic/atomic.hpp Don't know if that's the most elegant way, but at least boost builds fine with this fix.
Concerning dev-util/boost-build-1.54.0, I add to suppress the folowing lines from the ebuild to be able to emerge it successfuly (I assumed it was fixed upstream - but I have the test use flag unset, so I don't know) : "${FILESDIR}/${PN}-1.48.0-support_dots_in_python-buildid.patch" "${FILESDIR}/${PN}-1.50.0-fix-test.patch" \ and of course, to add : "${FILESDIR}/${PN}-1.54.0-fix-test.patch" \ "${FILESDIR}/${PN}-1.54.0-support_dots_in_python-buildid.patch" in the epatch list. Concerning dev-libs/boost-1.54.0, the dev-libs/boost-1.53.0 ebuild simply renamed in my overlay works fine. So I could emerge successfuly both packages in their 1.54.0 versions.
any activity on this bug? can't leave w/ 1.53 anymore...
(In reply to octoploid from comment #4) > I got several: > error: ‘uintptr_t’ was not declared in this scope > during the build. > > Fixed by including <stdint.h> in: > ./boost/log/detail/intptr_t.hpp > ./boost/atomic/atomic.hpp > > Don't know if that's the most elegant way, but at least > boost builds fine with this fix. do you upgrade to glibc-2.18? see bug #482372
(In reply to Dennis 'dlan' Lan from comment #7) > (In reply to octoploid from comment #4) > > I got several: > > error: ‘uintptr_t’ was not declared in this scope > > during the build. > > > > Fixed by including <stdint.h> in: > > ./boost/log/detail/intptr_t.hpp > > ./boost/atomic/atomic.hpp > > > > Don't know if that's the most elegant way, but at least > > boost builds fine with this fix. > > do you upgrade to glibc-2.18? see bug #482372 Yes.
I don't see any reason why gentoo is holding back boost 1.54 I am running boost 1.54 right after the offical release, and I see no package that build failed with boost 1.54. anyway, for those want to install boost1.54, please fetch the ebuild from gentoo-zh overlay, if you don't want to add that overlay.
+ 27 Aug 2013; Sergey Popov <pinkbyte@gentoo.org> +boost-build-1.54.0.ebuild, + +files/boost-build-1.54.0-fix-test.patch, + +files/boost-build-1.54.0-support_dots_in_python-buildid.patch: + Version bump, wrt bug #475712 + 27 Aug 2013; Sergey Popov <pinkbyte@gentoo.org> +boost-1.54.0.ebuild: + Version bump, wrt bug #475712 In tree, hardmasked for testing. Thanks to all.
according to http://www.boost.org/users/history/version_1_54_0.html there needs to be four more patches. and according to https://bugs.gentoo.org/show_bug.cgi?id=482372 there should be one more patch applied to boost in order to build agains glibc-2.18 and also according to https://svn.boost.org/trac/boost/ticket/8772 should be one more patch applied to boost in order to build boost with gcc 4.6.X with C++11 enabled. please add above SIX mentioned patches.