at www.boost.org, new version 1.36 of the boost C++ libraries can be downloaded. dev-libs/boost may be updated to the new version
*** Bug 235040 has been marked as a duplicate of this bug. ***
*** Bug 235039 has been marked as a duplicate of this bug. ***
Created attachment 163171 [details, diff] patch from 1.35.0-r1 to 1.36.0
Created attachment 163172 [details, diff] patch from 1.35.0-r1 to 1.36.0
Created attachment 163173 [details, diff] the only patch needed from boost-patches-1.35.0-2.tar.bz2
Created attachment 163174 [details, diff] fixes building of tools
Created attachment 163176 [details, diff] removes uses of deprecate boos::filesystem::leaf()
boost-1.36.0 is out! woohoo! ;) New Libraries: Accumulators, Exception, Units, Unordered. Updated Libraries: Asio, Assign, Foreach, Function, Hash, Interprocess, Intrusive, Math, Multi-index Containers, MPI, PtrContainer, Spirit, Thread, Wave, Xpressive. 1.36.0 compiles cleanly on gcc-4.3, so most patches from 1.35.0-r1 are obsolete now. The only patch still needed is 07_all_1.35.0-fix_mpi_installation.patch. There was also a missing include while building tools, see patch boost-1.36.0-tools-build-fix.patch Some of the regression tests use deprecated boost::filesystem::leaf() which is now filename(). Patch: boost-1.36.0-deprecated-leaf.patch I tested on amd64/gcc-4.3.1-r1: dev-util/boost-build with USE="" and USE="examples python" dev-libs/boost with USE="" and USE="doc expat icu mpi tools"
oh, and please change the subject to contain the string 1.36.0, so others can find that bug without going through all of the boost bugs... Thanks
Thanks for the patches. Are you sure that 05_all_1.35.0-0001-date_time-gcc-4.3-fix.bug-1615-not_included.patch is not needed anymore?
I know that that patch hasn't been applied upstream. It's name tells me it was a fix for gcc-4.3. Since it compiled cleanly without it on gcc-4.3.1, I'd say the fix isn't nedded anymore.
hmm, according to http://svn.boost.org/trac/boost/changeset/48192 the patch boost-1.36.0-deprecated-leaf.patch is not needed. If someone has a working gcc-4.4.0 already installed: I'll accept patches :)
Ok, thats another approach to fix the problem. But you're talking about Changeset 48192, boost-1.36.0 is Changeset 48100. I'd rather get rid of deprecated code, but feel free to patch filesystem/operations.hpp instead. I'll see what I can do about gcc-4.4.
Created attachment 163287 [details, diff] add deprecated names again
gcc-4.4.0 status report: "It's time to start moving GCC 4.4.0 towards a release, with a release target date in Q4 2008 or Q1 2009." I'll see about it next year then ;)
Created attachment 163290 [details, diff] the updated patch for boost-1.36.0.ebuild
Created attachment 163468 [details, diff] fix tests Regression tools seem to be put in different location than where the ebuild expects them. Also, compiler_status is not an implicit target, so have to be requested explicitly. Furthermore -- there's no reliable way (reliable as in defined by PMS and/or supported by all PMs) to tell in src_compile whether src_test is going to be run, so building of tests postprocessors should happen in _test. I haven't come with a hack that would work for einfos in pkg_setup though.
Created attachment 163470 [details, diff] globbing and jobs Tiziano, this is about using ls in ebuilds and --jobs in MAKE_OPTS we talked about in #-cpp.
Created attachment 163474 [details, diff] fix for compiler_status regression tool I don't know if anyone apart from me run tests on 1.36, but this one seems to be needed to make them work. Basicly, it looks like filesystem::path::string() was not including trailing slash on directory entries before, but that seems to have changed. It has to be applied together with boost-1.36.0-restore-deprecated-basic_directory_entry-names.patch .
This works fine, I've compiled it with GCC 4.2.4 (because 4.4 is not supported yet) and then compiled the rb_libtorrent trunk (my own ebuild) against it. I'm afraid that many packages won't build against it yet (stable rb_libtorrent for example), but it would be nice to have it in the tree anyways (hard masked, I suppose).
Tested with GCC 4.1.2 and rebuilt OpenOffice 2.4.1 on x86 fine.
I've been playing around trying to get boost-1.36.0 to compile, but it keeps dieing due to jam errors: ... * Using the following options to build: * gentoorelease --without-mpi --user-config=/var/tmp/portage/dev-libs/boost-1.36.0/work/boost_1_36_0/user-config.jam --boost-build=/usr/share/boost-build warning: Graph library does not contain optional GraphML reader. note: to enable GraphML support, set EXPAT_INCLUDE and EXPAT_LIBPATH to the note: directories containing the Expat headers and libraries, respectively. warning: skipping optional Message Passing Interface (MPI) library. note: to enable MPI support, add "using mpi ;" to user-config.jam. note: to suppress this message, pass "--without-mpi" to bjam. note: otherwise, you can safely ignore this message. Building Boost.Regex with the optional Unicode/ICU support disabled. Please refer to the Boost.Regex documentation for more information (don't panic: this is a strictly optional feature). /usr/share/boost-build/build/virtual-target.jam:423: in _adjust-name from module object(file-target)@3389 error: <tag>@rulename is present but is not the only <tag> feature /usr/share/boost-build/build/virtual-target.jam:215: in abstract-file-target.__init__ from module object(file-target)@3389 /usr/share/boost-build/build/virtual-target.jam:531: in object(file-target)@3389.__init__ from module object(file-target)@3389 /usr/share/boost-build/kernel/class.jam:93: in class.new from module class ... Am I using the incorrect version of jam (Boost.Jam 03.1.14)? Or does 1.36 require Unicode/ICU or GraphML to compile? I've also tried compileing with gcc-4.3.1 and gcc-4.1.2 and get the same results. EBo -- --------- obligatory emerge info: Portage 2.1.4.4 (default-linux/x86/2007.0/desktop, gcc-4.1.2, glibc-2.7-r2, 2.6.25-gentoo-r7 i686) ================================================================= System uname: 2.6.25-gentoo-r7 i686 Intel(R) Pentium(R) Dual CPU T2330 @ 1.60GHz Timestamp of tree: Sat, 27 Sep 2008 14:15:01 +0000 app-shells/bash: 3.2_p33 dev-java/java-config: 1.3.7, 2.1.6 dev-lang/python: 2.4.4-r14, 2.5.2-r7 dev-python/pycrypto: 2.0.1-r6 sys-apps/baselayout: 1.12.11.1 sys-apps/sandbox: 1.2.18.1-r2 sys-devel/autoconf: 2.13, 2.61-r2 sys-devel/automake: 1.5, 1.7.9-r1, 1.8.5-r3, 1.9.6-r2, 1.10.1-r1 sys-devel/binutils: 2.18-r3 sys-devel/gcc-config: 1.4.0-r4 sys-devel/libtool: 1.5.26 virtual/os-headers: 2.6.23-r3 ACCEPT_KEYWORDS="x86" CBUILD="i686-pc-linux-gnu" CFLAGS="-march=prescott -O2 -pipe -fomit-frame-pointer" CHOST="i686-pc-linux-gnu" CONFIG_PROTECT="/etc /usr/kde/3.5/env /usr/kde/3.5/share/config /usr/kde/3.5/shutdown /usr/share/config /var/lib/hsqldb" CONFIG_PROTECT_MASK="/etc/ca-certificates.conf /etc/env.d /etc/env.d/java/ /etc/fonts/fonts.conf /etc/gconf /etc/php/apache2-php5/ext-active/ /etc/php/cgi-php5/ext-active/ /etc/php/cli-php5/ext-active/ /etc/revdep-rebuild /etc/terminfo /etc/texmf/web2c /etc/udev/rules.d" CXXFLAGS="-march=prescott -O2 -pipe -fomit-frame-pointer" DISTDIR="/usr/portage/distfiles" FEATURES="ccache distlocks metadata-transfer parallel-fetch sandbox sfperms strict unmerge-orphans userfetch" GENTOO_MIRRORS="http://gentoo.osuosl.org/ ftp://distro.ibiblio.org/pub/linux/distributions/gentoo/ http://distro.ibiblio.org/pub/linux/distributions/gentoo/ ftp://ftp.gtlib.gatech.edu/pub/gentoo http://www.gtlib.gatech.edu/pub/gentoo ftp://mirror.iawnet.sandia.gov/pub/gentoo/ ftp://ftp.ussg.iu.edu/pub/linux/gentoo http://cudlug.cudenver.edu/gentoo/ http://gentoo.mirrors.pair.com/ ftp://gentoo.mirrors.pair.com/ http://gentoo.mirrors.tds.net/gentoo ftp://gentoo.mirrors.tds.net/gentoo http://gentoo.netnitco.net ftp://gentoo.netnitco.net/pub/mirrors/gentoo/source/ http://mirror.espri.arizona.edu/gentoo/ http://prometheus.cs.wmich.edu/gentoo http://mirror.mcs.anl.gov/pub/gentoo/ ftp://mirror.mcs.anl.gov/pub/gentoo/ http://gentoo.cites.uiuc.edu/pub/gentoo/ ftp://gentoo.cites.uiuc.edu/pub/gentoo/ http://mirror.fslutd.org/linux/distributions/gentoo/ ftp://mirror.fslutd.org/linux/distributions/gentoo/ nehet" LINGUAS="en" MAKEOPTS="-j4" PKGDIR="/usr/portage/packages" PORTAGE_RSYNC_OPTS="--recursive --links --safe-links --perms --times --compress --force --whole-file --delete --stats --timeout=180 --exclude=/distfiles --exclude=/local --exclude=/packages" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" PORTDIR_OVERLAY="/usr/portage/local/layman/pd-overlay /usr/portage/local/layman/science /usr/local/portage_overlays /old_root/home/ebo/gtd/projects/computer/local_portage/ref/local-portage" SYNC="rsync://rsync.namerica.gentoo.org/gentoo-portage" USE="X a52 aac acl acpi alsa arts audiofile bash-completion berkdb blas blender-game bluetooth bzip2 cairo cdr cli cracklib crypt css cups curl cvs dbus divx dri dvd dvdr dvdread eds emacs emboss encode esd evo fam ffmpeg fftw firefox fortran ftp gd gdbm gif git gmedia gnome gpg gpm graphviz gstreamer gtk hal hddtemp hdf5 iconv ieee1394 ipv6 ipw3945 isdnlog jack java javascript jpeg jpeg2k kde kerberos lapack laptop latex ldap lm_sensors mad midi mikmod mp3 mpeg mudflap ncurses netcdf nls nptl nptlonly ogg openal opengl openmp osc oss pam pcre pdf perl png portaudio pppd python qt3 qt3support qt4 quicktime readline realmedia reflection sasl sdl session spell spl ssl subversion svg tcl tcpd threads tiff tk truetype unicode usb vorbis win32codecs wmf wmp x86 xine xml xorg xpm xv zlib" ALSA_CARDS="hda-intel" ALSA_PCM_PLUGINS="adpcm alaw asym copy dmix dshare dsnoop empty extplug file hooks iec958 ioplug ladspa lfloat linear meter mmap_emul mulaw multi null plug rate route share shm softvol" APACHE2_MODULES="actions alias auth_basic authn_alias authn_anon authn_dbm authn_default authn_file authz_dbm authz_default authz_groupfile authz_host authz_owner authz_user autoindex cache dav dav_fs dav_lock deflate dir disk_cache env expires ext_filter file_cache filter headers include info log_config logio mem_cache mime mime_magic negotiation rewrite setenvif speling status unique_id userdir usertrack vhost_alias" ELIBC="glibc" INPUT_DEVICES="keyboard mouse synaptics evdev" KERNEL="linux" LCD_DEVICES="bayrad cfontz cfontz633 glk hd44780 lb216 lcdm001 mtxorb ncurses text" LINGUAS="en" USERLAND="GNU" VIDEO_CARDS="i810 vesa" Unset: CPPFLAGS, CTARGET, EMERGE_DEFAULT_OPTS, FFLAGS, INSTALL_MASK, LANG, LC_ALL, LDFLAGS, PORTAGE_COMPRESS, PORTAGE_COMPRESS_FLAGS, PORTAGE_RSYNC_EXTRA_OPTS
(In reply to comment #22) > Am I using the incorrect version of jam (Boost.Jam 03.1.14)? I suspect you forgot to bump boost-build first.
Rebuilding OOo 2.4.1 using G++ 4.3.1 + Boost 1.36.0 right now. I also have a Layman tar-type overlay prepared that I'll be uploading to this bug.
Created attachment 166766 [details] Gzip'ed tar (overlay contents, use with the attached XML file and Layman) Make sure that this and the XML overlay file are in the same directory, otherwise Layman probably won't find the TAR file.
Created attachment 166768 [details] XML overlay manifest for Layman Make sure this is in the same directory as the matching TAR file.
(In reply to comment #23) > (In reply to comment #22) > > Am I using the incorrect version of jam (Boost.Jam 03.1.14)? > I suspect you forgot to bump boost-build first. Doh, I missed that one. Everything is building now...
Update: both Inkscape 0.46 and OpenOffice.org 2.4.1 build fine with Boost 1.36.0 + G++ 4.3.1-r1
Tiziano: ping?
I have gcc-4.3.2, glibc-2.7-r2, and boost-1.36.0 (patches: fix_mpi_installation, tools-build-fix, restore-deprecated-basic_directory_entry_names). I have had no problems building openoffice-3.0.0. Why the delay?
In the mean time boost 1.37 has been released.
I'd lvoe to see boost 1.37.0 in portage =[
In my mind (at least), we really ought to split the Boost ebuild up into a dependency ebuild (most likely 1.33.0, 1.34.0, and 1.34.1) that other packages can depend on and a development ebuild that is sync'ed with releases from upstream. Not having the latest version of Boost at your disposal is a pain if you are a C++ developer; however, Boost's API isn't stable between releases (considering that Boost is a continually-growing collection of libraries, all maintained by different developers as opposed to a single library maintained by a single development team) which means that we can't provide only the latest version.
That sounds like a good idea, but what about putting ebuilds for 1.36.0 and 1.37.0 (testing it right now) into the tree for now? Hardmask it if you want to protect the innocent, but let the devs get easy access to the bleeding edge. That's what gentoo is all about...
Alrighty. 1.37.0 builds out-of-box over here. I am posting an updated overlay .tar with the 1.36.0 and 1.37.0 ebuilds as well as the 1.36.0 patches.
Created attachment 170758 [details] Updated overlay contents
Is there a way we can add the boost-overlay through layman?
There's a separate bug for 1.37.0: http://bugs.gentoo.org/show_bug.cgi?id=245617
(In reply to comment #37) > Is there a way we can add the boost-overlay through layman? > There's no boost repository, what Lucas meant are ebuilds uploaded to this bug, that you can stick in your local repository.
@Zeke: yes, just download the .xml and the .tar files into the same directory and then run "layman -o boost-overlay.xml -s boost-overlay" from that directory. @Lukasz: man layman :)
(In reply to comment #38) > There's a separate bug for 1.37.0: > http://bugs.gentoo.org/show_bug.cgi?id=245617 > I don't have the linked patches in my ebuild for 1.37, I'll get them in there ASAP.
Created attachment 171027 [details] Updated overlay contents (again)
Created attachment 171782 [details] Another update to the boost-overlay's contents
Created attachment 172174 [details] Yet ANOTHER update to the boost-overlay's contents (with the working patch now)
Any new on that one? I'd really appreciate having at least 1.36 in portage. Have it hardmasked if it causes trouble but there's lots of developers amongst gentoo users.... Thanks... Stephan
My apologies that it takes so long to get this done, but my time is limited and slotting boost is unfortunately not so easy. I'm done with 1.36.0 and 1.37.0 so far, but 1.35.0 still needs some more work. If you want to help, please check out the ebuilds in my overlay. Boost: http://git.overlays.gentoo.org/gitweb/?p=dev/dev-zero.git;a=tree;f=dev-libs/boost;hb=HEAD Boost-Build: http://git.overlays.gentoo.org/gitweb/?p=dev/dev-zero.git;a=tree;f=dev-util/boost-build;hb=HEAD If someone knows pkgconfig and/or eselect I'd appreciate if you'd have time to write a corresponding file/module for boost. I included all the patches posted here in the tarballs. Thanks to Lucas, Łukasz and Christoph!
(In reply to comment #46) > If someone knows pkgconfig and/or eselect I'd appreciate if you'd have time to > write a corresponding file/module for boost. I could do eselect before the end of this week. I'd just need to clarify something: we want lib symlinks pointing from libboost_foo.{so,a} to libboost_foo-${version_with_underscores}.{so,a}, right? Seems reasonable as ${version_with_underscores} doesn't include minor on which you are not slotting.
Yes. And also the -mt versions. I'ven seen lotsa different ways of installing it and this one still strikes me as the easiest and most practical. Any objections? Thanks! Stephan
By the way, to make things a little more complicated, how about some sort of split ebuild thing here? I can see three major reasons: 1) some people keep asking about header only versions and this could probably provided that way. 2) The whole bunch takes quite some time to build, sometimes unnecessarily 3) In that way I was hoping to have ebuilds for not-yet-boost libs such as boost.logging and boost.process. The latter I find rather useful, but to build it you need a fully checked out and built boost dist and the result often needs lots of work to integrate into a system installed version. By splitting boost one would be able to build these libs just the way the official parts are built. Any thoughts on that? Thanks, Stephan
(In reply to comment #49) > By the way, to make things a little more complicated, > how about some sort of split ebuild thing here? I'm sorry, but I'm not going to split the boost ebuild any further. The reason is that it makes things more complicated for the maintenance and keywording since upstream doesn't support it natively. I always hope that the ebuild format will once provide better support for that.
(In reply to comment #47) > (In reply to comment #46) > > If someone knows pkgconfig and/or eselect I'd appreciate if you'd have time to > > write a corresponding file/module for boost. > > I could do eselect before the end of this week. I'd just need to clarify > something: we want lib symlinks pointing from libboost_foo.{so,a} to > libboost_foo-${version_with_underscores}.{so,a}, right? Seems reasonable as > ${version_with_underscores} doesn't include minor on which you are not > slotting. > Right. I'd also like to see eselect setting a symlink for the includes, /usr/share/boostbook-${MAJOR_PV} and maybe for the tools and for bjam. What's not needed is a symlink for /usr/share/boost-build since that is hardcoded in the corresponding bjam anyway. TIA
Created attachment 174313 [details] Proposed module. Here it is. I tested it as thoroughly as I could, but as usually not warranty implied. Also, once I finished it, I wonder whether (as boost-build is a distinct ebuild) there shouldn't be bjam.eselect as a different tool.
Created attachment 175472 [details] Modules with py mpi. Updated to support python's mpi.so symlink.
(In reply to comment #49) > By the way, to make things a little more complicated, > how about some sort of split ebuild thing here? > > I can see three major reasons: > > 1) some people keep asking about header only versions and this could probably > provided that way. > > 2) The whole bunch takes quite some time to build, sometimes unnecessarily > > 3) In that way I was hoping to have ebuilds for not-yet-boost libs such as > boost.logging and boost.process. The latter I find rather useful, but to build > it you need a fully checked out and built boost dist and the result often needs > lots of work to integrate into a system installed version. By splitting boost > one would be able to build these libs just the way the official parts are > built. Any thoughts on that? > > Thanks, > > Stephan > I agree that having a way to build "parts" of boost would be useful. Instead of breaking up boost into many ebuilds we could use useflags and even possibly a USE_EXPAND="BOOST_LIBS" sorta like xorg-server uses. This would allow other ebuilds to select exactly which parts of boost are needed. I created a bug report here: http://bugs.gentoo.org/show_bug.cgi?id=260404 in which I did just this. And it seems to work fine. Maybe you can test it too.
Done. Thanks to everyone helping with that :)
