boost-1.34.0 was released ... would be great to see it in portage ... Reproducible: Always
Second that motion assuming it has python-2.5 support.
Created attachment 119666 [details] boost-1.34.0.ebuild
Created attachment 119667 [details] dev-util/boost-build-1.34.0.ebuild
Bjam breaks horribly with gcc 4.2 if optimizations are enabled. This seems to be a known problem: http://lists.alioth.debian.org/pipermail/pkg-boost-devel/2006-May/000424.html I've tested with both -O2 and -O3, and they both lead to bjam segfaulting when invoked. The solution for me was to filter out -O, -O1, -O2, -O3 from CFLAGS in the ebuild: replace-flags "-O3" "-O0" replace-flags "-O2" "-O0" replace-flags "-O1" "-O0" replace-flags "-O" "-O0" in the src_compile section. Yes, there are certainly more elegant ways to proceed, but I don't know jack abou ebuilds, so bear with me :) Boost 1.34 is now being compiled with gcc-4.2, I'll report back if further problems arise.
(In reply to comment #1) > Second that motion assuming it has python-2.5 support. > Samuli, I've recompiled boost 1.33 with python 2.5 and it works flawlessly. I had searched in the mailing list archives before upgrading from python 2.4 and the only issues I saw were on 64-bit platforms, but, IIRC, were not boost's fault.
(In reply to comment #4) > Bjam breaks horribly with gcc 4.2 if optimizations are enabled. This seems to > be a known problem: > > http://lists.alioth.debian.org/pipermail/pkg-boost-devel/2006-May/000424.html > > I've tested with both -O2 and -O3, and they both lead to bjam segfaulting when > invoked. The solution for me was to filter out -O, -O1, -O2, -O3 from CFLAGS in > the ebuild: > > replace-flags "-O3" "-O0" > replace-flags "-O2" "-O0" > replace-flags "-O1" "-O0" > replace-flags "-O" "-O0" > > in the src_compile section. Yes, there are certainly more elegant ways to > proceed, but I don't know jack abou ebuilds, so bear with me :) > > Boost 1.34 is now being compiled with gcc-4.2, I'll report back if further > problems arise. > > > Just for clarity, the problems affects only the boost-build package. The boost libraries can be compiled without dropping optimizations.
> Boost 1.34 is now being compiled with gcc-4.2, I'll report back if further > problems arise. there is at lease one bug with boost and gcc-4.2, which break boost's smart pointers ... from the feedback i got from the boost list, i suppose boost-1.34 won't support gcc-4.2 at all ...
(In reply to comment #7) > > Boost 1.34 is now being compiled with gcc-4.2, I'll report back if further > > problems arise. > > there is at lease one bug with boost and gcc-4.2, which break boost's smart > pointers ... from the feedback i got from the boost list, i suppose boost-1.34 > won't support gcc-4.2 at all ... > Yup, I'm taking a look at the mailing list archives right now. Well, hopefully 1.34.1 will be released soon. Bottom line is then that it is better to keep that gcc 4.1 around for a while, just in case :)
Gcc 4.2 isn't among the supported compilers for the release - it may work for release 1.34.1 but they're not officially supporting it with this release. I for one would like to see a better quality ebuild for boost - creation of a bjam.eclass, and support for cross compiling boost e.g. creating both 32bit and 64 bit versions of the libraries.
@James: did you compare the boost-1.34.0_beta with boost-1.33.1 already? There's a lot of improvement already there. And there aren't enough bjam-based packages around which would justify a separate eclass.
Yes I have looked into the boost 1.34. I was referring to the quality of the ebuild already posted here - its missing a few things - the test suite etc. I don't think that number of bjam packages should be a factor for determining when an eclass should be created - bjam is quite a complex build system to configure, why should this effort be duplicated more than once? Its better to use the facilities available to avoid duplicating effort from the start, rather than having to refactor at a later date. If I get a spare moment I'll have a go at writing the appropriate files.
well, as far as I know, there is a big number of issues in version 1.34.0, Why should we wait for 1.34.1, it shouldn't be long :)
Done.
(In reply to comment #4) I've tested with both -O2 and -O3, and they both lead to bjam segfaulting when > invoked. The solution for me was to filter out -O, -O1, -O2, -O3 from CFLAGS in > the ebuild: > > replace-flags "-O3" "-O0" > replace-flags "-O2" "-O0" > replace-flags "-O1" "-O0" > replace-flags "-O" "-O0" > > in the src_compile section. Yes, there are certainly more elegant ways to > proceed, but I don't know jack abou ebuilds, so bear with me :) When I saw this I just wanted to remind you that gcc accepts -O4 as well and interprets it as -O3. Same for -O4444 and any other number above 3. So what you have to filter out in cases where optimization breaks something is a regular expression, something like "-O[0123456789]+". And do not forget to check if -Os also breaks things.
The problem with bjam segfaulting is not because of the optimizations but because it violates strict aliasing and the optimizations therefore break it. Adding "-fno-strict-aliasing" helped although it's not the most preferable solution.
