Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 283106 - version bump: dev-libs/boost-1.41.0
Summary: version bump: dev-libs/boost-1.41.0
Status: RESOLVED FIXED
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: New packages (show other bugs)
Hardware: All Linux
: High enhancement (vote)
Assignee: C++ Team [disbanded]
URL: http://www.boost.org/users/download/v...
Whiteboard:
Keywords:
Depends on:
Blocks: 282138
  Show dependency tree
 
Reported: 2009-08-29 10:53 UTC by Andreas Sturmlechner
Modified: 2011-06-16 13:50 UTC (History)
16 users (show)

See Also:
Package list:
Runtime testing required: ---


Attachments
boost-1.40.0_ebuild.patch (boost-1.40.0_ebuild.patch,1.81 KB, patch)
2009-10-20 21:26 UTC, Lars Wendler (Polynomial-C)
Details | Diff
boost-1.40.0-build.log (boost-1.40.0-build.log,14.84 KB, text/plain)
2009-10-21 14:54 UTC, Jean-Francois Ostiguy
Details
emerge.info (emerge.info,3.85 KB, text/plain)
2009-10-21 18:58 UTC, Jean-Francois Ostiguy
Details
Fix for upstream bug 3560 (duplicate-name-of-actual-target-graph-parallel-1.40.patch,1.43 KB, patch)
2009-11-10 08:30 UTC, Sebastian Luther (few)
Details | Diff
workaround for gcc-4.4 bug (gcc-4.4-assert-workaround-1.40.patch,747 bytes, patch)
2009-11-10 08:37 UTC, Sebastian Luther (few)
Details | Diff
Boost.Parameter should not depend on Boost.Python (upstream bug 3490) (parameter-needs-python-1.40.patch,2.97 KB, patch)
2009-11-10 21:07 UTC, Sebastian Luther (few)
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Andreas Sturmlechner gentoo-dev 2009-08-29 10:53:29 UTC
Most important: "Works on GCC 4.4" :)

Also brings various other fixes of course... I posted the URL to the changelog.

Reproducible: Always
Comment 1 Tiziano Müller gentoo-dev 2009-08-29 17:31:06 UTC
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.
Comment 2 Andreas Sturmlechner gentoo-dev 2009-08-29 18:20:03 UTC
Ok, that's kind of a setback...
Comment 3 John (EBo) David 2009-10-02 15:18:50 UTC
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 --
Comment 4 Jean-Francois Ostiguy 2009-10-20 15:47:55 UTC
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.

 
 
Comment 5 Lars Wendler (Polynomial-C) gentoo-dev 2009-10-20 21:26:22 UTC
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.
Comment 6 Dirkjan Ochtman gentoo-dev 2009-10-21 13:22:25 UTC
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.
Comment 7 Jean-Francois Ostiguy 2009-10-21 14:54:47 UTC
Created attachment 207830 [details]
boost-1.40.0-build.log
Comment 8 Jean-Francois Ostiguy 2009-10-21 14:57:33 UTC
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.
Comment 9 Dirkjan Ochtman gentoo-dev 2009-10-21 15:02:12 UTC
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?
Comment 10 Jean-Francois Ostiguy 2009-10-21 18:58:26 UTC
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.
Comment 11 John (EBo) David 2009-10-21 20:13:29 UTC
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?

Comment 12 Dirkjan Ochtman gentoo-dev 2009-10-22 10:43:00 UTC
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").
Comment 13 Łukasz Michalik 2009-10-22 11:03:15 UTC
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.
Comment 14 Dirkjan Ochtman gentoo-dev 2009-10-22 11:36:59 UTC
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.
Comment 15 John (EBo) David 2009-10-22 13:05:29 UTC
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.

Comment 16 Dirkjan Ochtman gentoo-dev 2009-10-22 13:24:56 UTC
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.
Comment 17 Dirkjan Ochtman gentoo-dev 2009-10-22 16:20:08 UTC
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?
Comment 18 John (EBo) David 2009-10-22 17:19:02 UTC
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>                                                                     
Comment 19 Jean-Francois Ostiguy 2009-10-22 19:11:13 UTC
(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. 
Comment 20 Sebastian Luther (few) 2009-10-25 16:41:04 UTC
(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.
Comment 21 Sebastian Luther (few) 2009-10-25 21:28:58 UTC
I filed an upstream bug:
https://svn.boost.org/trac/boost/ticket/3560
Comment 22 Sebastian Luther (few) 2009-11-10 08:30:24 UTC
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.
Comment 23 Sebastian Luther (few) 2009-11-10 08:37:56 UTC
Created attachment 209815 [details, diff]
workaround for gcc-4.4 bug
Comment 24 Jean-Francois Ostiguy 2009-11-10 18:08:25 UTC
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 !
Comment 25 Sebastian Luther (few) 2009-11-10 21:07:29 UTC
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".
Comment 26 Sebastian Luther (few) 2009-11-10 21:11:40 UTC
According to bug 290243, boost-1.35.0-endian.hpp-hppa.patch should also be applied.
Comment 27 Sebastian Luther (few) 2009-11-12 20:53:38 UTC
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
Comment 28 Sebastian Luther (few) 2009-11-15 13:38:23 UTC
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
Comment 29 Sebastian Luther (few) 2009-11-15 19:32:20 UTC
(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.
Comment 30 Sebastian Luther (few) 2009-11-18 18:32:36 UTC
Boost 1.41 is out. Ebuild is in my overlay.
Comment 31 Sebastian Luther (few) 2009-11-19 20:33:14 UTC
Thanks to upstream dev volodya, the boost-1.41 ebuild in my overlay now supports other mpi implementations than openmpi.
Comment 32 Sebastian Luther (few) 2009-11-19 21:11:31 UTC
(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.
Comment 33 Henrique Rodrigues 2009-12-07 13:19:43 UTC
Should this bug be closed, now that boost-1.41.0 is in the Portage tree?
Comment 34 Dirkjan Ochtman gentoo-dev 2009-12-07 13:30:36 UTC
Yes, I'll resolve this, since 1.41 is in the tree already.
Comment 35 Martin Mokrejš 2009-12-08 18:14:22 UTC
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
Comment 36 Sebastian Luther (few) 2009-12-08 18:28:12 UTC
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.
Comment 37 Martin Mokrejš 2009-12-08 20:36:50 UTC
(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.
Comment 38 Martin Mokrejš 2009-12-08 22:13:30 UTC
(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.
Comment 39 Sebastian Luther (few) 2009-12-09 08:01:15 UTC
(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...
Comment 40 Sebastian Luther (few) 2009-12-09 12:19:12 UTC
Dependency changed to mpich2[cxx,threads] in =dev-libs/boost-1.41.0-r1 without a bump. Thanks for the report.
Comment 41 Martin Mokrejš 2009-12-11 00:25:12 UTC
[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')
Comment 42 John (EBo) David 2009-12-11 10:12:58 UTC
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 --
Comment 43 Sebastian Luther (few) 2009-12-11 21:48:43 UTC
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
Comment 44 John (EBo) David 2009-12-11 23:46:26 UTC
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 --
Comment 45 Sebastian Luther (few) 2009-12-12 08:42:24 UTC
(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.
Comment 46 Dirkjan Ochtman gentoo-dev 2009-12-12 09:00:58 UTC
This is now about 1.41, not 1.40.
Comment 47 John (EBo) David 2009-12-12 12:24:40 UTC
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").
> 

Comment 48 Sebastian Luther (few) 2009-12-12 20:19:02 UTC
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.
Comment 49 John (EBo) David 2009-12-12 23:16:22 UTC
(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 --
Comment 50 Martin Mokrejš 2009-12-13 17:29:09 UTC
Maybe this link help somebody? http://dev.gentoo.org/~jsbronder/empi.xml
(and CCing Justin directly).
Comment 51 Sebastian Luther (few) 2010-01-20 16:39:50 UTC
If someone is interested in testing 1.42: bug 301643.
Comment 52 Andrey Antipov 2011-06-16 12:34:25 UTC
Can anyone look at the bug 329207 . Same behaviour with mpi and python flags simultaneosly turned on on x64-macos?