Version 1.38 is out (and on Sourceforge). New libraries include: Flyweight ScopeExitSwap Updated libraries: Accumulators, Any, Asio, Config, Date_Time, Exception, Filesystem, Graph, Hash, Interprocess, Intrusive, Lexical Cast, Math, Multi-index Containers, Proto, Regex, Thread, TR1, Type Traits, Unordered, Xpressive. Also includes experimental support for CMake, but my guess is it'd be best to stick with boost-build.
Reassigning to cpp herd.
What is taking so long? I'd be happy to bug test if that's needed. Gentoo's latest release in the main Portage branch still being 1.35.0 is unacceptable.
If you remove the patchset from the 1.37 ebuild you can use the ebuild also for 1.38 and test the new version. (I have done this)
(In reply to comment #3) > If you remove the patchset from the 1.37 ebuild you can use the ebuild also for > 1.38 and test the new version. (I have done this) > I can verify that this works.
From the 1.37.0 patchset, 02_all_1.37.0-function-templates-compile-fix.patch and 07_all_1.35.0-fix_mpi_installation.patch apply cleanly. The others, 01_all_1.36.0-tools-build-fix.patch and 03_all_1.36.0-compiler_status-trailing_slash.patch no longer need to be applied to Boost 1.38.0.
(In reply to comment #3) > If you remove the patchset from the 1.37 ebuild you can use the ebuild also for > 1.38 and test the new version. (I have done this) This would be a somewhat decent workaround if the 1.37 ebuild was in the Portage tree.
(In reply to comment #6) > (In reply to comment #3) > > If you remove the patchset from the 1.37 ebuild you can use the ebuild also for > > 1.38 and test the new version. (I have done this) > > This would be a somewhat decent workaround if the 1.37 ebuild was in the > Portage tree. > The 1.37 ebuild *is* in the Portage tree, it's just slotted. Also, I can confirm that modifying the 1.37 ebuild to remove the two patches that don't apply works.
I'm sorry for being a general jerk. I'm still interested in bug testing and doing whatever possible to quicken the process of this package's stabilization.
media-gfx/inkscape-0.46-r5 and app-office/openoffice-3.0.1 build successfully with boost 1.38 and GCC 4.1.2
(In reply to comment #9) > media-gfx/inkscape-0.46-r5 and app-office/openoffice-3.0.1 build successfully > with boost 1.38 and GCC 4.1.2 > Actually, it was app-office/openoffice-3.0.0 that I built.
boost 1.38.0 wouldn't even install for me (install stage of merge): ...updated 7544 targets... * Ups, tried to remove 'libboost_date_time-1_38.a' which is a a real file instead of a symlink * * ERROR: dev-libs/boost-1.38.0-r1 failed. * Call stack: * ebuild.sh, line 48: Called src_install * environment, line 3837: Called die * The specific snippet of code: * die "slotting/naming of the libs broken!"; * The die message: * slotting/naming of the libs broken! I used the 1.37.0-r* ebuild and 1.37.0 patchset, (02_all_1.37.0-function-templates-compile-fix.patch and 07_all_1.35.0-fix_mpi_installation.patch) any ideas what's going wrong ? did you encounter the same problem at the beginning ? thanks
*** Bug 268554 has been marked as a duplicate of this bug. ***
1.39 cannot be as easily be build as 1.38 boost build patch cannot be applied boost lamets that it does not like link=static,shared and link-runtime=static, shared. Only either static or shared is accepted. error: link=shared together with runtime-link=static is not allowed error: such property combination is either impossible error: or too dangerious to be of any use Even if either only static or only shared is specified it fails to build:
Created attachment 190655 [details] boost-1.39.0.ebuild Here's the code that produces the shared/static error message (from Jamroot): rule handle-static-runtime ( properties * ) { # Using static runtime with shared libraries is impossible on Linux, # and dangerous on Windows. Therefore, we disallow it. This might # be drastic, but it was disabled for a while with nobody complaining. # For CW, static runtime is needed so that std::locale works. if <link>shared in $(properties) && <runtime-link>static in $(properties) && ! ( <toolset>cw in $(properties) ) { ECHO "error: link=shared together with runtime-link=static is not allowed" ; ECHO "error: such property combination is either impossible " ; ECHO "error: or too dangerious to be of any use" ; EXIT ; } } Disabling static linking for the runtime libraries seems to be the best solution. Also, the 'optimization' and 'debug-symbols' features do not take 'none' but 'on'/'off' (in user-config.jam). Those are the only two things I changed.
boost-patches-1.39.0.tbz2 doesn't even exist, Markus did you comment that line out when compiling ?
Created attachment 190661 [details, diff] tools_wave_cpp.patch - fix namespace errors Whoops, I just copied my boost-patches-1.38.0.tbz2. One other change is that files/buildid.patch is no longer used. So after 40 minutes I get this error: gcc.compile.c++ ../bin.v2/tools/wave/build/gcc-4.3/gentoorelease/link-static/threading-multi/cpp.o wave/build/../cpp.cpp: In function 'int do_actual_work(std::string, std::istream&, const boost::program_options::variables_map&, bool)': wave/build/../cpp.cpp:802: error: 'string' was not declared in this scope wave/build/../cpp.cpp:802: error: template argument 1 is invalid wave/build/../cpp.cpp:802: error: template argument 2 is invalid wave/build/../cpp.cpp:802: error: no matching function for call to 'boost::program_options::variable_value::as() const' wave/build/../cpp.cpp:839: error: 'string' was not declared in this scope wave/build/../cpp.cpp:839: error: template argument 1 is invalid wave/build/../cpp.cpp:839: error: template argument 2 is invalid wave/build/../cpp.cpp:839: error: no matching function for call to 'boost::program_options::variable_value::as() const' ... many template warnings ... "i686-pc-linux-gnu-g++" -ftemplate-depth-128 -O2 -march=pentium-m -pipe -O0 -finline-functions -Wno-inline -Wall -pthread -DBOOST_ALL_NO_LIB=1 -DBOOST_FILESYSTEM_STATIC_LINK=1 -DBOOST_SYSTEM_STATIC_LINK=1 -DBOOST_THREAD_POSIX -DBOOST_THREAD_USE_LIB=1 -DDATE_TIME_INLINE -DNDEBUG -I".." -c -o "../bin.v2/tools/wave/build/gcc-4.3/gentoorelease/link-static/threading-multi/cpp.o" "wave/build/../cpp.cpp" ...failed gcc.compile.c++ ../bin.v2/tools/wave/build/gcc-4.3/gentoorelease/link-static/threading-multi/cpp.o... ...skipped <p../dist/bin>wave for lack of <p../bin.v2/tools/wave/build/gcc-4.3/gentoorelease/link-static/threading-multi>cpp.o... gcc.compile.c++ ../bin.v2/tools/bcp/gcc-4.3/gentoorelease/link-static/bcp_imp.o ...failed updating 1 target... ...skipped 1 target... ...updated 40 targets... Looks like a simple syntax error. They wrote 'string' instead of 'std::string'. I've attached a patch, but it'll be a while before I get any results.
Builds clean now. I guess the question comes down to what's more useful: (1) link=shared,static runtime-link=shared (2) link=static runtime-link=shared,static (Presuming that (2) builds fine.)
I'm not finding the boost-patches-1.38.0.tbz2 either...
(In reply to comment #18) > I'm not finding the boost-patches-1.38.0.tbz2 either... > It's the same as boost-patches-1.37.0.tbz2, with a couple of patches left out. Scroll up to the talk about boost-1.38.0 for details (comment #5 in particular).
(In reply to comment #14) > Also, the 'optimization' and 'debug-symbols' features do not take > 'none' but 'on'/'off' (in user-config.jam). From 'boost-1.38.0-r1.ebuild': > # Maintainer information: > # The debug-symbols=none and optimization=none > # are not official upstream flags but a Gentoo > # specific patch to make sure that all our > # CXXFLAGS/LDFLAGS are being respected. > # Using optimization=off would for example add > # "-O0" and override "-O2" set by the user. > # Please take a look at the boost-build ebuild > # for more infomration. Looks like a problem with your boost-build-1.39.0.ebuild, since 'none' should be valid on gentoo. (In reply to comment #17) > Builds clean now. I guess the question comes down to what's more useful: > (1) link=shared,static runtime-link=shared > (2) link=static runtime-link=shared,static > > (Presuming that (2) builds fine.) I suspect that (1) is more useful. I could be a little lost... but I think the ideal setup would be to have both of: (3) link=shared runtime-link=shared (4) link=static runtime-link=static Can we just run 'bjam' twice with different link settings? Or will that cause it to recompile all of the source? I haven't had a chance to try this myself, unfortunately... I'll reply with my results if/when I do.
(In reply to comment #20) > (In reply to comment #14) > > Also, the 'optimization' and 'debug-symbols' features do not take > > 'none' but 'on'/'off' (in user-config.jam). > > From 'boost-1.38.0-r1.ebuild': > > # Maintainer information: > > # The debug-symbols=none and optimization=none > > # are not official upstream flags but a Gentoo > > # specific patch to make sure that all our > > # CXXFLAGS/LDFLAGS are being respected. > > # Using optimization=off would for example add > > # "-O0" and override "-O2" set by the user. > > # Please take a look at the boost-build ebuild > > # for more infomration. > > Looks like a problem with your boost-build-1.39.0.ebuild, since 'none' should > be valid on gentoo. Exactly :) > > (In reply to comment #17) > > Builds clean now. I guess the question comes down to what's more useful: > > (1) link=shared,static runtime-link=shared > > (2) link=static runtime-link=shared,static > > > > (Presuming that (2) builds fine.) > > I suspect that (1) is more useful. > > I could be a little lost... but I think the ideal setup would be to have both > of: > (3) link=shared runtime-link=shared > (4) link=static runtime-link=static > > Can we just run 'bjam' twice with different link settings? Or will that cause > it to recompile all of the source? I haven't had a chance to try this myself, > unfortunately... I'll reply with my results if/when I do. It would be possible but probably not necessary. If you check the contents of libboost_LIB-s.a and libboost_LIB.a you'll notice that they're the same. My guess is that this link/runtime-link stuff comes from the "portability" of boost-build for various systems. On Windows you can for example have a shared lib with a matching static lib and you link your app to the static lib, but the static lib is nothing more than a proxy for the runtime lib. So you have link=static, runtime-link=shared. But on Unix you usually have link=shared,runtime-link=shared or link=static,runtime-link=static. Now, I have to look at the build system to determine what makes more sense and gives us what we want.
(In reply to comment #21) > But on Unix you usually have link=shared,runtime-link=shared or > link=static,runtime-link=static. > > Now, I have to look at the build system to determine what makes more sense and > gives us what we want. > I wonder if 'runtime-link' is necessary to specify at all. I.e., would 'bjam' have sane 'runtime-link' defaults for 'link=static,shared'?
Bugs #263580 and #270622 depend on this (boost-1.37 has a broken header file).
Done, thanks for helping.
