I guess using -DBoost_ADDITIONAL_VERSIONS=1.62 could be an alternative solution.

from espressopp.

Okay, working on it!

from espressopp.

Ok, I got it! It is not a problem with boost-1.56, but gcc-5.1:
https://travis-ci.org/junghans/espressopp/builds/71349254

from espressopp.

The problem persists with gcc-5.2!

from espressopp.

Just FYI debian and fedora are switching to gcc-5, so we will need to fix this soon, otherwise we have some fun time at the workshop.
https://travis-ci.org/junghans/espressopp/jobs/76716709

from espressopp.

With Python 2.7.9, gcc 5.2 and boost 1.58 I can compile but espressopp programs crash when using mpirun.

from espressopp.

So, this might be a combination of new gcc and old boost then?

from espressopp.

Using the espressopp bundled boost, I have a similar build error. So, if you have a recent compiler you need a recent boost as you say.

Still, a more recent boost compiles but fails at runtime whenever it is run with mpirun, with a segmentation fault.

from espressopp.

Don't you need to have openmpi compiled with gcc 5 ?

from espressopp.

I think that it is the case. ldd refers to the same libstdc++ and libgcc for openmpi and a program compiled with g++ 5.2. Is that a good enough verification?

from espressopp.

The issue is back with gcc-6.2 and boost-1.62.0, see https://bugs.gentoo.org/show_bug.cgi?id=595830

from espressopp.

@junghans @MrTheodor
Hi, I might have found a problem. Can you see the FindBoost.cmake or which version of cmake (cmake system modules might not be updated to deal with newer Boost versions)?
Because for example I noticed that it looks there is no branch in that file to deal with the higher version, doesn't find the Boost system component (which SHOULD! How can it compile and pass checks without that dependencies (filesystem depends on that)) and goes into:

else()
message(WARNING "Imported targets not available for Boost version ${Boost_VERSION}")
set(_Boost_IMPORTED_TARGETS FALSE)

In my OSX I use Boost 1.6.1, here a part of my cmake config command:

$ cmake ..
-- The C compiler identification is AppleClang 7.3.0.7030031
-- The CXX compiler identification is AppleClang 7.3.0.7030031
-- Boost version: 1.61.0
-- Found the following Boost libraries:
-- mpi
-- python
-- serialization
-- system
-- filesystem
-- mpi4py version: 2.0.0

In the snapshot you link, the system component is not found and that's a problem.

I use Cmake 3.6.1.
In my FindBoost.cmake, there's a branch with that:

elseif(NOT Boost_VERSION VERSION_LESS 106100 AND Boost_VERSION VERSION_LESS 106200)
set(_Boost_CHRONO_DEPENDENCIES system)
set(_Boost_CONTEXT_DEPENDENCIES thread chrono system date_time)
set(_Boost_COROUTINE_DEPENDENCIES context system)
set(_Boost_FILESYSTEM_DEPENDENCIES system)
set(_Boost_IOSTREAMS_DEPENDENCIES regex)
set(_Boost_LOG_DEPENDENCIES date_time log_setup system filesystem thread regex chrono atomic)
set(_Boost_MATH_DEPENDENCIES math_c99 math_c99f math_c99l math_tr1 math_tr1f math_tr1l atomic)
set(_Boost_MPI_DEPENDENCIES serialization)
set(_Boost_MPI_PYTHON_DEPENDENCIES python mpi serialization)
set(_Boost_RANDOM_DEPENDENCIES system)
set(_Boost_THREAD_DEPENDENCIES chrono system date_time atomic)
set(_Boost_WAVE_DEPENDENCIES filesystem system serialization thread chrono date_time atomic)
set(_Boost_WSERIALIZATION_DEPENDENCIES serialization)
else()
message(WARNING "Imported targets not available for Boost version ${Boost_VERSION}")
set(_Boost_IMPORTED_TARGETS FALSE)

and later

else()

The user has not requested an exact version. Among known

versions, find those that are acceptable to the user request.

Note: When adding a new Boost release, also update the dependency

information in _Boost_COMPONENT_DEPENDENCIES and

_Boost_COMPONENT_HEADERS. See the instructions at the top of

_Boost_COMPONENT_DEPENDENCIES.

set(_Boost_KNOWN_VERSIONS ${Boost_ADDITIONAL_VERSIONS}
"1.61.0" "1.61" "1.60.0" "1.60"

I think Cmake 3.4.3 is being used or less since in then stops at 1.59. If you try to run with at least cmake 3.5.0 you might be able to run since I see the FindBoost.cmake is different and supports higher Boost versions.

In addition, if that works with later cmake version, it might still fail at test time, since mpi4py-2.0.0 is being used and changes I posted which seems to work (at least on Travis and on my system!) are still not included in the repo.

from espressopp.

I have a version where we ship the latest FindBoost.cmake in espressopp/cmake as we do for the mpi4py and fftw3. Also, a trivial question that might even solve it.
I just saw that version E++ (1.9.3, not the latest!) doesn't require the system component for Boost, and filesystem in higher versions looks like it depends on that... and latest E++ versions require it.
Why this change? What if system is included? Does just including that might solve it in this case?
Let me know, I can prepare something for trying.

from espressopp.

I see there was no test target included.
E++ 1.9.3 with the previously mentioned version of the programs/libraries (boost 1.61, AppleClang 7.3.0.7030031) builds ok on my system.
I have a commit on a branch on top of tag 1.9.3 that we could try or can generate a patch from that commit:
https://github.com/fedepad/espressopp/tree/higher-boost-version-comp-for-tag-1-9-3

from espressopp.

@junghans I see in the build cmake 3.6.2 is used. I checked FindBoost.cmake for that version and it's basically the same to 3.6.1 so I expect the system FindBoost.cmake module to have still the problem to handle the newer Boost version 1.62, but I bet should work fine if you would use boost 1.61.
The FindBoost.cmake I included in my branch is the latest in the Cmake master branch and it looks should be able to handle that version of boost that's being used by the build.

from espressopp.

I am usually against ship cmake find macros, but I guess should do it for 3.6.x until they fixed it.

@fedepad : Can you report that bug upstream (https://gitlab.kitware.com/cmake/cmake)

from espressopp.

@junghans Ok, I will look into that!

from espressopp.

So I checked CMake branches on gitlab and on the branch "release" they made the same changes I did to FindBoost.cmake like 14 hours ago to add boost 1.62 support, too bad I didn't even think about contributing there my changes!
https://gitlab.kitware.com/cmake/cmake/blob/release/Modules/FindBoost.cmake
Since it's release branch I expect should be in the next release...but I can ask!

from espressopp.

@junghans Did you had any chance to check that integrating the "new" FindBoost.cmake would solve the build issue reported last time?
Anyway, Cmake is out with a release candidate (3.7.0-rc1) which has the right FindBoost.cmake to deal with boost 1.62. Probably it hasn't already reached some of the distros package managers...

from espressopp.