Most important: "Works on GCC 4.4" :) Also brings various other fixes of course... I posted the URL to the changelog. Reproducible: Always
It doesn't work more with gcc-4.4 than 1.39.0. Without the -Wno-strict-antialiasing boost-1.40.0 still fails the compilation. Plus the mpi-patch doesn't apply anymore but upstream didn't fix it properly either.
Ok, that's kind of a setback...
Can you point be to the ebuild so I can take a stab at it? I've been having problem with an incompatibility with some code which *requires* mpich2 to be installed. Boost (<=1.39.0) fails to compile with mpich2, but works for openmpi. I'd like to poke around with the latest verson to start with. Thanks and best regards, EBo --
By deafault, gcc 4.4.X turns on optimizations that require strict assumptions about aliasing. When theses assumptions are violated, you get a warning/error because applying the optimizations (which effectively transform the code) would produce invalid code. I think the fix that was applied in ebuilds is incorrect. The correct fix (see below) should be applied to all versions of boost when compiled with > gcc-4.4. The issue is the flag: -Wno-strict-aliasing This flag instructs g++ to turn off the ***warnings*** and ignores potentially invalid code. It should not be used unless you know for a fact that the flagged code snippet is correct ( the analysis is complex and g++ is often too conservative). The flag that needs to be used is -fno-strict-aliasing This flag will actually turns off the potentially problematic optimization (and the warnings as well) instead of applying it silently.
Created attachment 207747 [details, diff] boost-1.40.0_ebuild.patch This is the patch I'm currently using for boost. With the exception of the -fno-strict-aliasing stuff I've been using this version for weeks now and even used it while doing "emerge -e @world" twice on my ~amd64 test machine.
I've put a package.masked version of boost-1.40 in the tree. Please see if it works for you, so we can start to unmask it. I'd especially like some testing on sparc, mips and hppa, because those have been problematic for 1.37/1.39.
Created attachment 207830 [details] boost-1.40.0-build.log
It fails for me on amd64 ( see attachment above). The problems seems to have something to do with the naming scheme of the mpi libraries.
Thanks for trying! Actually, it looks like that has to do with the GraphMT library, which I think only gets configured if you have the expat use flag enabled. Can you post your emerge --info as well, please?
Created attachment 207853 [details] emerge.info emerge.info for boost-1.40.0 I do not think that the issue is expat. If I set USE=-mpi, emerge succeeds.
it does not work for me at all; and I have not had enough time to diagnose the problem... What I do know though is that boost is sensitive to the MPI installation. While I forget the details, I think that it did not run nicely with mpich2, but did ok with openmpi. Unfortunately for me, some of the climate models I was playing with require mpich2 and does not play well with openmpi... So, which mpi flavour covers your yummy stuff?
jfostiguy, thanks for the info, I'll look into it. John David, let me know if you have some more detailed info on what breaks (e.g. the configure or the compile or 'just' your app). In any case, the current version of the boost ebuild pulls in openmpi, but mpich2 is also in the portage tree, so I guess we could depend on those. Not sure how the boost build config will select the mpi to use, though (we currently don't pass anything to indicate it should use openmpi, just that it should be compiled "using mpi").
Bug 267818 describes the issue with mpich2 and boost. Someone with spare cycles could check whether it's still the issue with more recent versions. Also, mpich2 and openmpi rightfully block each other, so people can't use openmpi just for boost.
lmi: thanks for the info. I've looked into the mpich2 situation. It looks like the issues with boost vs mpich2 just revolve around the mpic++ vs. mpicxx executable, meaning that this should be fixed if you use mpich2-1.1.1 or later. If someone gives it a whirl to see if it'll work, I think I should add a >=sys-cluster/mpich2-1.1.1[cxx] alternative dependency for the mpi use flag.
I've spent a little time poking at this and I cannot get it to build at all. I'll see if I can break away some time to beat on it this weekend (but midterms are coming up)... An observation I can comment on at the moment is: virtual/mpi is probably a better dependency than working out the differences between mpich2/openmpi/etc. I have been playing with using empi (so I can eselect between different mpi implementation). I'm playing with those to see if I can get all the dependencies to resolve.
John, can you post your emerge log? I might be able to make sense of it (and I'm trying to keep in touch with the Boost developers, so maybe they'll pitch in). Depending on virtual/mpi sounds good as far as I'm concerned, though we'd have to test if it works with lam-mpi, too.
JF: so, weird-ass thing, but it looks like boost does compile if you try it a second time after encountering that error (this is with +mpi, openmpi-1.2.9). Can you try if that works for you, as well?
Dirkjan, No it dies both times with the following appended trace. The problem appears that it might be boost-build. I was able to get it to start building with -mpi. EBo -- ============== boost build trace =============== boost> sudo ebuild boost-1.40.0.ebuild digest compile >>> Creating Manifest for /home/ebo/gtd/projects/computer/local_portage/ref/local-portage/dev-libs/boost >>> Existing ${T}/environment for 'boost-1.40.0' will be sourced. Run >>> 'clean' to start with a fresh environment. * boost_1_40_0.tar.bz2 RMD160 SHA1 SHA256 size ;-) ... [ ok ] * checking ebuild checksums ;-) ... [ ok ] * checking auxfile checksums ;-) ... [ ok ] * checking miscfile checksums ;-) ... [ ok ] * checking boost_1_40_0.tar.bz2 ;-) ... [ ok ] >>> Checking boost_1_40_0.tar.bz2's mtime... >>> WORKDIR is up-to-date, keeping... >>> It appears that 'boost-1.40.0' is already prepared; skipping. >>> Remove '/var/tmp/portage/dev-libs/boost-1.40.0/.prepared' to force prepare. >>> It appears that 'boost-1.40.0' is already configured; skipping. >>> Remove '/var/tmp/portage/dev-libs/boost-1.40.0/.configured' to force configuration. >>> Compiling source in /var/tmp/portage/dev-libs/boost-1.40.0/work/boost_1_40_0 ... * Using the following options to build: * --user-config="/var/tmp/portage/dev-libs/boost-1.40.0/work/boost_1_40_0/user-config.jam" --boost-build=/usr/share/boost-build-1_40 --prefix="/var/tmp/portage/dev-libs/boost-1.40.0/image//usr" --layout=versioned Building the Boost C++ Libraries. After the build, the headers will be located at /var/tmp/portage/dev-libs/boost-1.40.0/work/boost_1_40_0 The libraries will be located at /var/tmp/portage/dev-libs/boost-1.40.0/work/boost_1_40_0/stage/lib Use 'bjam install --prefix=<path>' if you wish to install headers and libraries to a different location and remove the source tree. warning: Building Boost.Regex with the optional Unicode/ICU support disabled. note: Please refer to the Boost.Regex documentation for more information note: this is a strictly optional feature. 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. /usr/share/boost-build-1_40/build/virtual-target.jam:1056: in virtual-target.register-actual-name from module virtual-target error: Duplicate name of actual target: <pstage/lib>libboost_graph_parallel-mt-1_40.so.1.40.0 error: previous virtual target { common%common.copy-libboost_graph_parallel-mt-1_40.so.1.40.0.SHARED_LIB { gcc%gcc.link.dll-libboost_graph_parallel-mt-1_40.so.1.40.0.SHARED_LIB { gcc%gcc.compile.c++-mpi_process_group.o.OBJ { mpi_process_group.cpp.CPP } } { gcc%gcc.compile.c++-tag_allocator.o.OBJ { tag_allocator.cpp.CPP } } { gcc%gcc.link.dll-libboost_mpi-mt-1_40.so.1.40.0.SHARED_LIB { gcc%gcc.compile.c++-broadcast.o.OBJ { broadcast.cpp.CPP } } { gcc%gcc.compile.c++-communicator.o.OBJ { communicator.cpp.CPP } } { gcc%gcc.compile.c++-computation_tree.o.OBJ { computation_tree.cpp.CPP } } { gcc%gcc.compile.c++-content_oarchive.o.OBJ { content_oarchive.cpp.CPP } } { gcc%gcc.compile.c++-environment.o.OBJ { environment.cpp.CPP } } { gcc%gcc.compile.c++-exception.o.OBJ { exception.cpp.CPP } } { gcc%gcc.compile.c++-graph_communicator.o.OBJ { graph_communicator.cpp.CPP } } { gcc%gcc.compile.c++-group.o.OBJ { group.cpp.CPP } } { gcc%gcc.compile.c++-intercommunicator.o.OBJ { intercommunicator.cpp.CPP } } { gcc%gcc.compile.c++-mpi_datatype_cache.o.OBJ { mpi_datatype_cache.cpp.CPP } } { gcc%gcc.compile.c++-mpi_datatype_oarchive.o.OBJ { mpi_datatype_oarchive.cpp.CPP } } { gcc%gcc.compile.c++-packed_iarchive.o.OBJ { packed_iarchive.cpp.CPP } } { gcc%gcc.compile.c++-packed_oarchive.o.OBJ { packed_oarchive.cpp.CPP } } { gcc%gcc.compile.c++-packed_skeleton_iarchive.o.OBJ { packed_skeleton_iarchive.cpp.CPP } } { gcc%gcc.compile.c++-packed_skeleton_oarchive.o.OBJ { packed_skeleton_oarchive.cpp.CPP } } { gcc%gcc.compile.c++-point_to_point.o.OBJ { point_to_point.cpp.CPP } } { gcc%gcc.compile.c++-request.o.OBJ { request.cpp.CPP } } { gcc%gcc.compile.c++-text_skeleton_oarchive.o.OBJ { text_skeleton_oarchive.cpp.CPP } } { gcc%gcc.compile.c++-timer.o.OBJ { timer.cpp.CPP } } { gcc%gcc.link.dll-libboost_serialization-mt-1_40.so.1.40.0.SHARED_LIB { gcc%gcc.compile.c++-basic_serializer_map.o.OBJ { basic_serializer_map.cpp.CPP } } { gcc%gcc.compile.c++-basic_text_iprimitive.o.OBJ { basic_text_iprimitive.cpp.CPP } } { gcc%gcc.compile.c++-basic_text_oprimitive.o.OBJ { basic_text_oprimitive.cpp.CPP } } { gcc%gcc.compile.c++-basic_xml_archive.o.OBJ { basic_xml_archive.cpp.CPP } } { gcc%gcc.compile.c++-binary_iarchive.o.OBJ { binary_iarchive.cpp.CPP } } { gcc%gcc.compile.c++-binary_oarchive.o.OBJ { binary_oarchive.cpp.CPP } } { gcc%gcc.compile.c++-extended_type_info.o.OBJ { extended_type_info.cpp.CPP } } { gcc%gcc.compile.c++-extended_type_info_typeid.o.OBJ { extended_type_info_typeid.cpp.CPP } } { gcc%gcc.compile.c++-extended_type_info_no_rtti.o.OBJ { extended_type_info_no_rtti.cpp.CPP } } { gcc%gcc.compile.c++-polymorphic_iarchive.o.OBJ { polymorphic_iarchive.cpp.CPP } } { gcc%gcc.compile.c++-polymorphic_oarchive.o.OBJ { polymorphic_oarchive.cpp.CPP } } { gcc%gcc.compile.c++-stl_port.o.OBJ { stl_port.cpp.CPP } } { gcc%gcc.compile.c++-text_iarchive.o.OBJ { text_iarchive.cpp.CPP } } { gcc%gcc.compile.c++-text_oarchive.o.OBJ { text_oarchive.cpp.CPP } } { gcc%gcc.compile.c++-void_cast.o.OBJ { void_cast.cpp.CPP } } { gcc%gcc.compile.c++-xml_grammar.o.OBJ { xml_grammar.cpp.CPP } } { gcc%gcc.compile.c++-xml_iarchive.o.OBJ { xml_iarchive.cpp.CPP } } { gcc%gcc.compile.c++-xml_oarchive.o.OBJ { xml_oarchive.cpp.CPP } } { gcc%gcc.compile.c++-basic_archive.o.OBJ { basic_archive.cpp.CPP } } { gcc%gcc.compile.c++-basic_iarchive.o.OBJ { basic_iarchive.cpp.CPP } } { gcc%gcc.compile.c++-basic_iserializer.o.OBJ { basic_iserializer.cpp.CPP } } { gcc%gcc.compile.c++-basic_oarchive.o.OBJ { basic_oarchive.cpp.CPP } } { gcc%gcc.compile.c++-basic_oserializer.o.OBJ { basic_oserializer.cpp.CPP } } { gcc%gcc.compile.c++-basic_pointer_iserializer.o.OBJ { basic_pointer_iserializer.cpp.CPP } } { gcc%gcc.compile.c++-basic_pointer_oserializer.o.OBJ { basic_pointer_oserializer.cpp.CPP } } } } { gcc%gcc.link.dll-libboost_serialization-mt-1_40.so.1.40.0.SHARED_LIB { gcc%gcc.compile.c++-basic_serializer_map.o.OBJ { basic_serializer_map.cpp.CPP } } { gcc%gcc.compile.c++-basic_text_iprimitive.o.OBJ { basic_text_iprimitive.cpp.CPP } } { gcc%gcc.compile.c++-basic_text_oprimitive.o.OBJ { basic_text_oprimitive.cpp.CPP } } { gcc%gcc.compile.c++-basic_xml_archive.o.OBJ { basic_xml_archive.cpp.CPP } } { gcc%gcc.compile.c++-binary_iarchive.o.OBJ { binary_iarchive.cpp.CPP } } { gcc%gcc.compile.c++-binary_oarchive.o.OBJ { binary_oarchive.cpp.CPP } } { gcc%gcc.compile.c++-extended_type_info.o.OBJ { extended_type_info.cpp.CPP } } { gcc%gcc.compile.c++-extended_type_info_typeid.o.OBJ { extended_type_info_typeid.cpp.CPP } } { gcc%gcc.compile.c++-extended_type_info_no_rtti.o.OBJ { extended_type_info_no_rtti.cpp.CPP } } { gcc%gcc.compile.c++-polymorphic_iarchive.o.OBJ { polymorphic_iarchive.cpp.CPP } } { gcc%gcc.compile.c++-polymorphic_oarchive.o.OBJ { polymorphic_oarchive.cpp.CPP } } { gcc%gcc.compile.c++-stl_port.o.OBJ { stl_port.cpp.CPP } } { gcc%gcc.compile.c++-text_iarchive.o.OBJ { text_iarchive.cpp.CPP } } { gcc%gcc.compile.c++-text_oarchive.o.OBJ { text_oarchive.cpp.CPP } } { gcc%gcc.compile.c++-void_cast.o.OBJ { void_cast.cpp.CPP } } { gcc%gcc.compile.c++-xml_grammar.o.OBJ { xml_grammar.cpp.CPP } } { gcc%gcc.compile.c++-xml_iarchive.o.OBJ { xml_iarchive.cpp.CPP } } { gcc%gcc.compile.c++-xml_oarchive.o.OBJ { xml_oarchive.cpp.CPP } } { gcc%gcc.compile.c++-basic_archive.o.OBJ { basic_archive.cpp.CPP } } { gcc%gcc.compile.c++-basic_iarchive.o.OBJ { basic_iarchive.cpp.CPP } } { gcc%gcc.compile.c++-basic_iserializer.o.OBJ { basic_iserializer.cpp.CPP } } { gcc%gcc.compile.c++-basic_oarchive.o.OBJ { basic_oarchive.cpp.CPP } } { gcc%gcc.compile.c++-basic_oserializer.o.OBJ { basic_oserializer.cpp.CPP } } { gcc%gcc.compile.c++-basic_pointer_iserializer.o.OBJ { basic_pointer_iserializer.cpp.CPP } } { gcc%gcc.compile.c++-basic_pointer_oserializer.o.OBJ { basic_pointer_oserializer.cpp.CPP } } } } } error: created from ./stage-proper error: another virtual target { common%common.copy-libboost_graph_parallel-mt-1_40.so.1.40.0.SHARED_LIB { gcc%gcc.link.dll-libboost_graph_parallel-mt-1_40.so.1.40.0.SHARED_LIB { gcc%gcc.compile.c++-mpi_process_group.o.OBJ { mpi_process_group.cpp.CPP } } { gcc%gcc.compile.c++-tag_allocator.o.OBJ { tag_allocator.cpp.CPP } } { gcc%gcc.link.dll-libboost_mpi-mt-1_40.so.1.40.0.SHARED_LIB { gcc%gcc.compile.c++-broadcast.o.OBJ { broadcast.cpp.CPP } } { gcc%gcc.compile.c++-communicator.o.OBJ { communicator.cpp.CPP } } { gcc%gcc.compile.c++-computation_tree.o.OBJ { computation_tree.cpp.CPP } } { gcc%gcc.compile.c++-content_oarchive.o.OBJ { content_oarchive.cpp.CPP } } { gcc%gcc.compile.c++-environment.o.OBJ { environment.cpp.CPP } } { gcc%gcc.compile.c++-exception.o.OBJ { exception.cpp.CPP } } { gcc%gcc.compile.c++-graph_communicator.o.OBJ { graph_communicator.cpp.CPP } } { gcc%gcc.compile.c++-group.o.OBJ { group.cpp.CPP } } { gcc%gcc.compile.c++-intercommunicator.o.OBJ { intercommunicator.cpp.CPP } } { gcc%gcc.compile.c++-mpi_datatype_cache.o.OBJ { mpi_datatype_cache.cpp.CPP } } { gcc%gcc.compile.c++-mpi_datatype_oarchive.o.OBJ { mpi_datatype_oarchive.cpp.CPP } } { gcc%gcc.compile.c++-packed_iarchive.o.OBJ { packed_iarchive.cpp.CPP } } { gcc%gcc.compile.c++-packed_oarchive.o.OBJ { packed_oarchive.cpp.CPP } } { gcc%gcc.compile.c++-packed_skeleton_iarchive.o.OBJ { packed_skeleton_iarchive.cpp.CPP } } { gcc%gcc.compile.c++-packed_skeleton_oarchive.o.OBJ { packed_skeleton_oarchive.cpp.CPP } } { gcc%gcc.compile.c++-point_to_point.o.OBJ { point_to_point.cpp.CPP } } { gcc%gcc.compile.c++-request.o.OBJ { request.cpp.CPP } } { gcc%gcc.compile.c++-text_skeleton_oarchive.o.OBJ { text_skeleton_oarchive.cpp.CPP } } { gcc%gcc.compile.c++-timer.o.OBJ { timer.cpp.CPP } } { gcc%gcc.link.dll-libboost_serialization-mt-1_40.so.1.40.0.SHARED_LIB { gcc%gcc.compile.c++-basic_serializer_map.o.OBJ { basic_serializer_map.cpp.CPP } } { gcc%gcc.compile.c++-basic_text_iprimitive.o.OBJ { basic_text_iprimitive.cpp.CPP } } { gcc%gcc.compile.c++-basic_text_oprimitive.o.OBJ { basic_text_oprimitive.cpp.CPP } } { gcc%gcc.compile.c++-basic_xml_archive.o.OBJ { basic_xml_archive.cpp.CPP } } { gcc%gcc.compile.c++-binary_iarchive.o.OBJ { binary_iarchive.cpp.CPP } } { gcc%gcc.compile.c++-binary_oarchive.o.OBJ { binary_oarchive.cpp.CPP } } { gcc%gcc.compile.c++-extended_type_info.o.OBJ { extended_type_info.cpp.CPP } } { gcc%gcc.compile.c++-extended_type_info_typeid.o.OBJ { extended_type_info_typeid.cpp.CPP } } { gcc%gcc.compile.c++-extended_type_info_no_rtti.o.OBJ { extended_type_info_no_rtti.cpp.CPP } } { gcc%gcc.compile.c++-polymorphic_iarchive.o.OBJ { polymorphic_iarchive.cpp.CPP } } { gcc%gcc.compile.c++-polymorphic_oarchive.o.OBJ { polymorphic_oarchive.cpp.CPP } } { gcc%gcc.compile.c++-stl_port.o.OBJ { stl_port.cpp.CPP } } { gcc%gcc.compile.c++-text_iarchive.o.OBJ { text_iarchive.cpp.CPP } } { gcc%gcc.compile.c++-text_oarchive.o.OBJ { text_oarchive.cpp.CPP } } { gcc%gcc.compile.c++-void_cast.o.OBJ { void_cast.cpp.CPP } } { gcc%gcc.compile.c++-xml_grammar.o.OBJ { xml_grammar.cpp.CPP } } { gcc%gcc.compile.c++-xml_iarchive.o.OBJ { xml_iarchive.cpp.CPP } } { gcc%gcc.compile.c++-xml_oarchive.o.OBJ { xml_oarchive.cpp.CPP } } { gcc%gcc.compile.c++-basic_archive.o.OBJ { basic_archive.cpp.CPP } } { gcc%gcc.compile.c++-basic_iarchive.o.OBJ { basic_iarchive.cpp.CPP } } { gcc%gcc.compile.c++-basic_iserializer.o.OBJ { basic_iserializer.cpp.CPP } } { gcc%gcc.compile.c++-basic_oarchive.o.OBJ { basic_oarchive.cpp.CPP } } { gcc%gcc.compile.c++-basic_oserializer.o.OBJ { basic_oserializer.cpp.CPP } } { gcc%gcc.compile.c++-basic_pointer_iserializer.o.OBJ { basic_pointer_iserializer.cpp.CPP } } { gcc%gcc.compile.c++-basic_pointer_oserializer.o.OBJ { basic_pointer_oserializer.cpp.CPP } } } } { gcc%gcc.link.dll-libboost_serialization-mt-1_40.so.1.40.0.SHARED_LIB { gcc%gcc.compile.c++-basic_serializer_map.o.OBJ { basic_serializer_map.cpp.CPP } } { gcc%gcc.compile.c++-basic_text_iprimitive.o.OBJ { basic_text_iprimitive.cpp.CPP } } { gcc%gcc.compile.c++-basic_text_oprimitive.o.OBJ { basic_text_oprimitive.cpp.CPP } } { gcc%gcc.compile.c++-basic_xml_archive.o.OBJ { basic_xml_archive.cpp.CPP } } { gcc%gcc.compile.c++-binary_iarchive.o.OBJ { binary_iarchive.cpp.CPP } } { gcc%gcc.compile.c++-binary_oarchive.o.OBJ { binary_oarchive.cpp.CPP } } { gcc%gcc.compile.c++-extended_type_info.o.OBJ { extended_type_info.cpp.CPP } } { gcc%gcc.compile.c++-extended_type_info_typeid.o.OBJ { extended_type_info_typeid.cpp.CPP } } { gcc%gcc.compile.c++-extended_type_info_no_rtti.o.OBJ { extended_type_info_no_rtti.cpp.CPP } } { gcc%gcc.compile.c++-polymorphic_iarchive.o.OBJ { polymorphic_iarchive.cpp.CPP } } { gcc%gcc.compile.c++-polymorphic_oarchive.o.OBJ { polymorphic_oarchive.cpp.CPP } } { gcc%gcc.compile.c++-stl_port.o.OBJ { stl_port.cpp.CPP } } { gcc%gcc.compile.c++-text_iarchive.o.OBJ { text_iarchive.cpp.CPP } } { gcc%gcc.compile.c++-text_oarchive.o.OBJ { text_oarchive.cpp.CPP } } { gcc%gcc.compile.c++-void_cast.o.OBJ { void_cast.cpp.CPP } } { gcc%gcc.compile.c++-xml_grammar.o.OBJ { xml_grammar.cpp.CPP } } { gcc%gcc.compile.c++-xml_iarchive.o.OBJ { xml_iarchive.cpp.CPP } } { gcc%gcc.compile.c++-xml_oarchive.o.OBJ { xml_oarchive.cpp.CPP } } { gcc%gcc.compile.c++-basic_archive.o.OBJ { basic_archive.cpp.CPP } } { gcc%gcc.compile.c++-basic_iarchive.o.OBJ { basic_iarchive.cpp.CPP } } { gcc%gcc.compile.c++-basic_iserializer.o.OBJ { basic_iserializer.cpp.CPP } } { gcc%gcc.compile.c++-basic_oarchive.o.OBJ { basic_oarchive.cpp.CPP } } { gcc%gcc.compile.c++-basic_oserializer.o.OBJ { basic_oserializer.cpp.CPP } } { gcc%gcc.compile.c++-basic_pointer_iserializer.o.OBJ { basic_pointer_iserializer.cpp.CPP } } { gcc%gcc.compile.c++-basic_pointer_oserializer.o.OBJ { basic_pointer_oserializer.cpp.CPP } } } } } error: created from ./stage-proper error: added properties: none error: removed properties: <threading>single /usr/share/boost-build-1_40/build/virtual-target.jam:480: in actualize-no-scanner from module object(file-target)@5992 /usr/share/boost-build-1_40/build/virtual-target.jam:130: in object(file-target)@5992.actualize from module object(file-target)@5992 /usr/share/boost-build-1_40/build-system.jam:713: in load from module build-system /usr/share/boost-build-1_40/kernel/modules.jam:283: in import from module modules /usr/share/boost-build-1_40/kernel/bootstrap.jam:138: in boost-build from module /var/tmp/portage/dev-libs/boost-1.40.0/work/boost_1_40_0/boost-build.jam:16: in module scope from module * ERROR: dev-libs/boost-1.40.0 failed: * building boost failed * * Call stack: * ebuild.sh, line 49: Called src_compile * environment, line 3717: Called die * The specific snippet of code: * ${BJAM} ${NUMJOBS} -q gentoorelease ${OPTIONS} threading=single,multi link=shared,static runtime-link=shared || die "building boost failed"; * * If you need support, post the output of 'emerge --info =dev-libs/boost-1.40.0', * the complete build log and the output of 'emerge -pqv =dev-libs/boost-1.40.0'. * This ebuild is from an overlay named 'EBo-overlays': '/home/ebo/gtd/projects/computer/local_portage/ref/local-portage/' * The complete build log is located at '/var/tmp/portage/dev-libs/boost-1.40.0/temp/build.log'. * The ebuild environment file is located at '/var/tmp/portage/dev-libs/boost-1.40.0/temp/environment'. * S: '/var/tmp/portage/dev-libs/boost-1.40.0/work/boost_1_40_0' boost>
(In reply to comment #17) > JF: so, weird-ass thing, but it looks like boost does compile if you try it a > second time after encountering that error (this is with +mpi, openmpi-1.2.9). > Can you try if that works for you, as well? > I consistently get the same error, even after a retry.
(In reply to comment #19) > > I consistently get the same error, even after a retry. > I get the same error on amd64 with USE="doc eselect mpi python -debug -expat -icu -test -tools" and sys-cluster/openmpi-1.3.3.
I filed an upstream bug: https://svn.boost.org/trac/boost/ticket/3560
Created attachment 209814 [details, diff] Fix for upstream bug 3560 This patch is needed to get around to build failure with +mpi. There ios another patch for gcc-4.4 needed.
Created attachment 209815 [details, diff] workaround for gcc-4.4 bug
I confirm that with the two patches applied, duplicate-name-of-actual-target-graph-parallel-1.40.patch gcc-4.4-assert-workaround-1.40.patch boost-1.40 emerge is successful with USE=mpi on both x86 and amd64. Thanks !
Created attachment 209860 [details, diff] Boost.Parameter should not depend on Boost.Python (upstream bug 3490) Should fix bug 291660. (Boost.Parameter broken if boost is installed with USE="-python"). Would be nice if someone with kde could test it. dev-libs/boost-1.39 seems to have the same problem (bug 283582). This bug has a minimal example program which works for me with the patch and USE="-python".
According to bug 290243, boost-1.35.0-endian.hpp-hppa.patch should also be applied.
I compiled a fair amount of boost's reverse-dependencies (including openoffice). There was only one boost related bug with a missing #include (bug 292874). The test suit doesn't look that good. I got 875 test failures, I guess lots of them are related to gcc-4.4. Seems to be usual that boost has test failures [1]. I'd say with the patches listed above, it's ready to leave p.mask. [1] http://www.boost.org/development/tests/release/developer/summary.html
I created an overlay [1] and put the modified boost-1.40.0-r1 ebuild together with a boost-1.41.0_beta1 ebuild in it. [1] git://github.com/few/few-s-gentoo-overlay.git
(In reply to comment #28) > I created an overlay [1] and put the modified boost-1.40.0-r1 ebuild together > with a boost-1.41.0_beta1 ebuild in it. > > [1] git://github.com/few/few-s-gentoo-overlay.git > For those interested: I added a boost-1.39.0-r1 to the overlay which contains fixes for bug 282138, bug 283582, bug 272086 and bug 290243.
Boost 1.41 is out. Ebuild is in my overlay.
Thanks to upstream dev volodya, the boost-1.41 ebuild in my overlay now supports other mpi implementations than openmpi.
(In reply to comment #31) > Thanks to upstream dev volodya, the boost-1.41 ebuild in my overlay now > supports other mpi implementations than openmpi. > Support added to 1.39 and 1.40. Make sure you use the boost-build from my overlay.
Should this bug be closed, now that boost-1.41.0 is in the Portage tree?
Yes, I'll resolve this, since 1.41 is in the tree already.
I do not think it is fixed in current ebuild: >>> Emerging (1 of 1) dev-libs/boost-1.41.0-r1 * boost_1_41_0.tar.bz2 RMD160 SHA1 SHA256 size ;-) ... [ ok ] * checking ebuild checksums ;-) ... [ ok ] * checking auxfile checksums ;-) ... [ ok ] * checking miscfile checksums ;-) ... [ ok ] * CPV: dev-libs/boost-1.41.0-r1 * REPO: gentoo * USE: amd64 elibc_glibc eselect kernel_linux mpi multilib python userland_GNU >>> Unpacking source... >>> Unpacking boost_1_41_0.tar.bz2 to /var/tmp/portage/dev-libs/boost-1.41.0-r1/work >>> Source unpacked in /var/tmp/portage/dev-libs/boost-1.41.0-r1/work >>> Preparing source in /var/tmp/portage/dev-libs/boost-1.41.0-r1/work/boost_1_41_0 ... * Applying remove-toolset-1.41.0.patch ... [ ok ] * Applying boost-1.41.0-parameter-needs-python.patch ... [ ok ] * Applying boost-1.41.0-mpi_process_group-missing-include.patch ... [ ok ] * Applying boost-1.41.0-iostreams-missing-include-guard.patch ... [ ok ] >>> Source prepared. >>> Configuring source in /var/tmp/portage/dev-libs/boost-1.41.0-r1/work/boost_1_41_0 ... * Writing new user-config.jam >>> Source configured. >>> Compiling source in /var/tmp/portage/dev-libs/boost-1.41.0-r1/work/boost_1_41_0 ... * Using the following command to build: * bjam-1_41 -j5 -q -d+2 gentoorelease --user-config="/var/tmp/portage/dev-libs/boost-1.41.0-r1/work/boost_1_41_0/user-config.jam" --boost-build=/usr/share/boost-build-1_41 --prefix="/var/tmp/portage/dev-libs/boost-1.41.0-r1/image//usr" --layout=versioned threading=single,multi link=shared,static runtime-link=shared Building the Boost C++ Libraries. After the build, the headers will be located at /var/tmp/portage/dev-libs/boost-1.41.0-r1/work/boost_1_41_0 The libraries will be located at /var/tmp/portage/dev-libs/boost-1.41.0-r1/work/boost_1_41_0/stage/lib Use 'bjam install --prefix=<path>' if you wish to install headers and libraries to a different location and remove the source tree. warning: Building Boost.Regex with the optional Unicode/ICU support disabled. note: Please refer to the Boost.Regex documentation for more information note: this is a strictly optional feature. 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. /usr/share/boost-build-1_41/build/virtual-target.jam:1066: in virtual-target.register-actual-name from module virtual-target error: Duplicate name of actual target: <pstage/lib>mpi.so error: previous virtual target { common%common.copy-mpi.so.PYTHON_EXTENSION { gcc%gcc.link.dll-mpi.so.PYTHON_EXTENSION { gcc%gcc.compile.c++-python/collectives.o.OBJ [cut] [cut] /usr/share/boost-build-1_41/build/virtual-target.jam:490: in actualize-no-scanner from module object(file-target)@5786 /usr/share/boost-build-1_41/build/virtual-target.jam:135: in object(file-target)@5786.actualize from module object(file-target)@5786 /usr/share/boost-build-1_41/build-system.jam:717: in load from module build-system /usr/share/boost-build-1_41/kernel/modules.jam:283: in import from module modules /usr/share/boost-build-1_41/kernel/bootstrap.jam:142: in boost-build from module /var/tmp/portage/dev-libs/boost-1.41.0-r1/work/boost_1_41_0/boost-build.jam:17: in module scope from module * ERROR: dev-libs/boost-1.41.0-r1 failed: * building boost failed * * Call stack: * ebuild.sh, line 55: Called src_compile * environment, line 3816: Called die * The specific snippet of code: * ${BJAM} ${NUMJOBS} -q -d+2 gentoorelease ${OPTIONS} threading=single,multi link=shared,static runtime-link=shared || die "building boost failed"; * * If you need support, post the output of 'emerge --info =dev-libs/boost-1.41.0-r1', * the complete build log and the output of 'emerge -pqv =dev-libs/boost-1.41.0-r1'. * The complete build log is located at '/var/tmp/portage/dev-libs/boost-1.41.0-r1/temp/build.log'. * The ebuild environment file is located at '/var/tmp/portage/dev-libs/boost-1.41.0-r1/temp/environment'. * S: '/var/tmp/portage/dev-libs/boost-1.41.0-r1/work/boost_1_41_0' # emerge --info Portage 2.1.7.11 (default/linux/amd64/10.0, gcc-4.4.2, glibc-2.11-r1, 2.6.29.6-default x86_64) ================================================================= System uname: Linux-2.6.29.6-default-x86_64-Intel-R-_Core-TM-2_Quad_CPU_Q9650_@_3.00GHz-with-gentoo-2.0.1 Timestamp of tree: Tue, 08 Dec 2009 18:00:01 +0000 app-shells/bash: 4.0_p35 dev-java/java-config: 2.1.10 dev-lang/python: 2.5.4-r3, 2.6.4, 3.1.1-r1 dev-util/cmake: 2.8.0 sys-apps/baselayout: 2.0.1 sys-apps/openrc: 0.5.3 sys-apps/sandbox: 2.2 sys-devel/autoconf: 2.13, 2.64 sys-devel/automake: 1.5, 1.9.6-r2, 1.10.2, 1.11 sys-devel/binutils: 2.20 sys-devel/gcc-config: 1.4.1 sys-devel/libtool: 2.2.6b virtual/os-headers: 2.6.30-r1 ACCEPT_KEYWORDS="amd64 ~amd64" ACCEPT_LICENSE="* -@EULA" CBUILD="x86_64-pc-linux-gnu" CFLAGS="-O2 -pipe -march=nocona" CHOST="x86_64-pc-linux-gnu" CONFIG_PROTECT="/etc /usr/share/X11/xkb /usr/share/config /var/bind /var/qmail/alias /var/qmail/control /var/spool/torque" CONFIG_PROTECT_MASK="/etc/ca-certificates.conf /etc/env.d /etc/env.d/java/ /etc/fonts/fonts.conf /etc/gconf /etc/gentoo-release /etc/revdep-rebuild /etc/sandbox.d /etc/terminfo" CXXFLAGS="-O2 -pipe -march=nocona" DISTDIR="/usr/portage/distfiles" FEATURES="assume-digests distlocks fixpackages news parallel-fetch protect-owned sandbox sfperms strict unmerge-logs unmerge-orphans userfetch" GENTOO_MIRRORS="http://distfiles.gentoo.org http://distro.ibiblio.org/pub/linux/distributions/gentoo" LDFLAGS="-Wl,-O1" MAKEOPTS="-j5" PKGDIR="/usr/portage/packages" PORTAGE_CONFIGROOT="/" 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" SYNC="rsync://rsync.gentoo.org/gentoo-portage" USE="X amd64 berkdb bzip2 cracklib crypt cxx dbus dri fortran gdbm gnutls hal iconv innodb java jce jpeg jpg kde laptop mmx modules mpi mpich2 multilib mysql ncurses nfs nls nptl nptlonly nsplugin opengl openssl pam pcre perl png python qt3support qt4 readline session sse sse2 ssl svg sysfs syslog tcpd unicode xorg zlib" ALSA_CARDS="ali5451 als4000 atiixp atiixp-modem bt87x ca0106 cmipci emu10k1x ens1370 ens1371 es1938 es1968 fm801 hda-intel intel8x0 intel8x0m maestro3 trident usb-audio via82xx via82xx-modem ymfpci" 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 evdev" KERNEL="linux" LCD_DEVICES="bayrad cfontz cfontz633 glk hd44780 lb216 lcdm001 mtxorb ncurses text" RUBY_TARGETS="ruby18" USERLAND="GNU" VIDEO_CARDS="vesa" Unset: CPPFLAGS, CTARGET, EMERGE_DEFAULT_OPTS, FFLAGS, INSTALL_MASK, LANG, LC_ALL, LINGUAS, PORTAGE_COMPRESS, PORTAGE_COMPRESS_FLAGS, PORTAGE_RSYNC_EXTRA_OPTS, PORTDIR_OVERLAY
Which MPI implementation are you using (including version and use flags)? Make sure you have a non-masked version of sys-devel/patch installed, then reinstall boost-build:1.41 and then try again.
(In reply to comment #36) > Which MPI implementation are you using (including version and use flags)? Make > sure you have a non-masked version of sys-devel/patch installed, then reinstall > boost-build:1.41 and then try again. > # emerge -pv mpich2 These are the packages that would be merged, in order: Calculating dependencies... done! [ebuild R ] sys-cluster/mpich2-1.2.1 USE="cxx fortran -debug -doc -mpi-threads -pvfs2 -romio -threads" 0 kB # emerge -pv sys-devel/patch These are the packages that would be merged, in order: Calculating dependencies... done! [ebuild R ] sys-devel/patch-2.5.9-r1 USE="-static" 198 kB I will try to follow your instructions. ;) Thanks.
(In reply to comment #37) > [ebuild R ] sys-cluster/mpich2-1.2.1 USE="cxx fortran -debug -doc > -mpi-threads -pvfs2 -romio -threads" 0 kB > [ebuild R ] sys-devel/patch-2.5.9-r1 USE="-static" 198 kB I did not update my patch program to 2.6 version, is that really what you want me to do? I did reinstall boost-build and then tried to recompile boot but still the same failure. I even tried x86_64-pc-linux-gnu-4.3.4 but with same results as with x86_64-pc-linux-gnu-4.4.2.
(In reply to comment #38) > I did not update my patch program to 2.6 version, is that really what you want > me to do? No, don't use patch-2.6 as long as it is masked. I just thought it could have caused this bug. (It was unmasked for some time.) > I did reinstall boost-build and then tried to recompile boot but > still the same failure. I even tried x86_64-pc-linux-gnu-4.3.4 but with same > results as with > x86_64-pc-linux-gnu-4.4.2. > I see it now. The compiler version doesn't matter. I guess we need to depend on mpich2[cxx,threads]. I tested this some time ago and it worked there. I wonder why it stopped...
Dependency changed to mpich2[cxx,threads] in =dev-libs/boost-1.41.0-r1 without a bump. Thanks for the report.
[ebuild N ] sys-cluster/openmpi-1.4 USE="cxx fortran -debug -heterogeneous -ipv6 -mpi-threads -pbs -romio -threads -vt" [ebuild N ] dev-libs/boost-1.41.0-r1 USE="eselect mpi python -debug -doc -expat -icu -test -tools" [blocks B ] sys-cluster/openmpi ("sys-cluster/openmpi" is blocking sys-cluster/mpich2-1.2.1) [blocks B ] sys-cluster/mpich2 ("sys-cluster/mpich2" is blocking sys-cluster/openmpi-1.4) * Error: The above package list contains packages which cannot be * installed at the same time on the same system. ('installed', '/', 'sys-cluster/mpich2-1.2.1', 'nomerge') pulled in by sys-cluster/mpich2 required by world ('ebuild', '/', 'sys-cluster/openmpi-1.4', 'merge') pulled in by >=sys-cluster/openmpi-1.2.9[cxx] required by ('ebuild', '/', 'dev-libs/boost-1.41.0-r1', 'merge')
As a note, at one point I got it to compile and play nicely by using sys-cluster/empi. I do not remember what all I had to do to pull this off, but I think I had to hack the virtual/mpi to include empi and then drop all the specific blocks in boost and some of the other packages and let virtual/mpi handle it. hope that helps. EBo --
sys-cluster/empi is not an MPI implementation. Have a look at its homepage [1]. (The package can be found in the science overlay.) For your block: That's just an unfortunate way to display the problem. It's not easy to get this right. The problem is that your mpich2 doesn't satisfy boost's mpi dep string. If it would, it would work. But since boost's mpi dep isn't satisfied, it picks the first (which is openmpi). Solution: Install mpich2 with USE="threads" on your own first. [1] http://dev.gentoo.org/~jsbronder/empi.xml
Sebastian, I am aware that sys-cluster/empi is not an MPI implementation, but allows me to eselect between multiple MPI implementations. This required me to experimentally modify boost and several other packages which have conflicting requirements for MPICH2/OpenMPI and get them to cohabitate by using sys-cluster/empi and setting, IIRC, virtual/MPI to depend on sys-cluster/empi. I was/am looking for a solution to deal with tools which I really want/need for my work which use one or the other MPI implementations. I know this is radical, but the way all the packages depend on mpich2/openmpi and the fact that they conflict is a real problem. EBo --
(In reply to comment #44) > Sebastian, > > I am aware that sys-cluster/empi is not an MPI implementation, but allows me to > eselect between multiple MPI implementations. This required me to > experimentally modify boost and several other packages which have conflicting > requirements for MPICH2/OpenMPI and get them to cohabitate by using > sys-cluster/empi and setting, IIRC, virtual/MPI to depend on sys-cluster/empi. > I was/am looking for a solution to deal with tools which I really want/need for > my work which use one or the other MPI implementations. > > I know this is radical, but the way all the packages depend on mpich2/openmpi > and the fact that they conflict is a real problem. > > EBo -- > Sorry for getting this wrong. I never used empi myself. I'll look into it.
This is now about 1.41, not 1.40.
Dirkjan Ochtman, I was out of town and missed this post entirely. I'm in the middle of finals now and do not have time to jump back into the middle of this. Could you email me after 12/26 to start hammering all this out? In short, various tool on the system require either mpich2 or openmpi. I do not recall correctly which ones had serious problems, but I think it was RegCM2 (a regional climate model) using mpich2 on my laptop. So, to answer your question I would have to compile and reconfigure about a half dozen or more apps/tools between mpich2/openmpi and see what breaks again. One of the experimental solutions I came up with was to hack virtual/mpi to depend on empi, and hack various ebuilds so that they did not depend on mpich2 or openmpi directly, but virtual/mpi. This still allows me to depend on !mpi-openmpi/openmpi (which is created by building openmpi using empi) so that if I know a package cannot work with openmpi... There are a couple of problem with this approach -- namely that it depends on empi which is not part of the man portage tree. Second, to get all this to really work it requires integration into the entire system. If this does look like a viable solution we would first have to bring empi into the portage tree, then systematically migrate everything which uses MPI into the new scheme. The advantage is that several of the MPI implementations can then cohabitate. Anyway, this will take days, if not weeks, to explore, test, and debug. So, if there is interest, please give me a ping after the holidays or the first of the year and I'll see if I can jump back into this. EBo -- (In reply to comment #12) > jfostiguy, thanks for the info, I'll look into it. > > John David, let me know if you have some more detailed info on what breaks > (e.g. the configure or the compile or 'just' your app). In any case, the > current version of the boost ebuild pulls in openmpi, but mpich2 is also in the > portage tree, so I guess we could depend on those. Not sure how the boost build > config will select the mpi to use, though (we currently don't pass anything to > indicate it should use openmpi, just that it should be compiled "using mpi"). >
I had a quick look at empi. Using it now as dependency for boost is not an option. To name some issues: * Having empi installed doesn't mean than an mpi implementation is installed. * No way to enforce use dependencies. * Package manager can't control (or even know) which implementation is used. (In reply to comment #47) > There are a couple of problem with this approach -- namely that it depends on > empi which is not part of the man portage tree. Second, to get all this to > really work it requires integration into the entire system. If this does look > like a viable solution we would first have to bring empi into the portage tree, > then systematically migrate everything which uses MPI into the new scheme. The > advantage is that several of the MPI implementations can then cohabitate. > Anyway, this will take days, if not weeks, to explore, test, and debug. So, if > there is interest, please give me a ping after the holidays or the first of the > year and I'll see if I can jump back into this. You are at the wrong address here. You should poke the empi maintainer or the gentoo-science herd in general to see what their plans are and if they need help. They have a mailing list and an IRC channel.
(In reply to comment #48) > I had a quick look at empi. Using it now as dependency for boost is not an > option. To name some issues: > > * Having empi installed doesn't mean than an mpi implementation is installed. I had not thought of that one, but I think the bigger question will be can we have multiple instances running at the same time. > * No way to enforce use dependencies. > * Package manager can't control (or even know) which implementation is used. I think I have sollutions for these, but want to fully test them before spewing forth. But as you mention later that discussion should move to a different venue. > You are at the wrong address here. You should poke the empi maintainer or the > gentoo-science herd in general to see what their plans are and if they need > help. They have a mailing list and an IRC channel. The real intent of my reply was to open up a discussion to see if this was a reasonable way to try to find a general solution to the underlying problem, and use boost as a platform to move forward. I'll consider your earlier points and take this unintended off-topic thread to more appropriate venue's. Thanks for the reply, EBo --
Maybe this link help somebody? http://dev.gentoo.org/~jsbronder/empi.xml (and CCing Justin directly).
If someone is interested in testing 1.42: bug 301643.
Can anyone look at the bug 329207 . Same behaviour with mpi and python flags simultaneosly turned on on x64-macos?
