> On Oct 6, 2016, at 12:43 PM, John Peterson <[email protected]> wrote: > > > > On Thu, Oct 6, 2016 at 9:50 AM, Boyce Griffith <[email protected] > <mailto:[email protected]>> wrote: > Folks -- > > Recently, I've started having trouble getting libMesh to recognize external > uninstalled boost libraries. I think it used to be easy: just unpack boost > somewhere and set BOOST_ROOT to that directory. I don't know if something has > changed in libMesh's boost m4, or if this is a change in boost, but now I > have to do something like the following: > > 1) unpack boost > 2) go into the boost directory and make a new "include" subdirectory > 3) link /path/to/boost_lib/boost to /path/to/boost_lib/include/boost > 4) configure libMesh using --with-boost=/path/to/boost_lib > > Is there some way to avoid steps 2) and 3)? > > Hmm... we recently updated the subset of boost bundled with libmesh, but I > don't think we've changed the m4 code that detects boost installations > (m4/ax_boost_base.m4) in quite some time. That m4 test is expecting headers > to be in $USER_PROVIDED_PATH/include, which I think is still how boost gets > installed... You mention that you manually "unpack" boost but (presumably) > don't use the provided scripts for actually installing it? Perhaps that is > the issue.
In principle, using ax_boost_base.m4 to detect Boost, I believe that if you are using header-only Boost libraries, all you need to do is to unpack Boost somewhere and set the environment variable BOOST_ROOT. (This is actually the logic that appears in ax_boost_base.m4 --- it tries to use BOOST_BASE to set up the CPP flags when testing for Boost.) I am pretty sure that with older versions of libMesh and/or Boost, I was able to do this: unpack Boost somewhere, set BOOST_ROOT, and configure libMesh. Now, however, the only way that I can reliably get libMesh configure to recognize where boost is installed is via --with-boost --- but the logic invoked by --with-boost=XXX assumes that XXX points to an "installed" version of Boost, so the headers need to be in XXX/include/boost. For instance, if I configure libMesh via: ./configure --disable-maintainer-mode \ --prefix=$HOME/sfw/killdevil/libmesh/master-opt \ --with-methods=opt \ PETSC_DIR=$HOME/sfw/petsc/current \ PETSC_ARCH=killdevil-gcc-opt \ CC=mpicc \ CXX=mpicxx \ CFLAGS="-O3" \ CXXFLAGS="-O3" \ BOOST_ROOT=$HOME/sfw/boost/boost_1_62_0 \ --disable-cxx11 \ --disable-openmp \ --disable-perflog \ --disable-strict-lgpl \ --disable-pthreads \ --disable-cppthreads \ --disable-unique-ptr I get: --------------------------------------------- ----- Configuring for optional packages ----- --------------------------------------------- checking for boostlib >= 1.57.0... configure: We could not detect the boost libraries (version 1.57 or higher). If you have a staged boost library (still not installed) please specify $BOOST_ROOT in your environment and do not give a PATH to --with-boost option. If you are sure you have boost installed, then check your version number looking in <boost/version.hpp>. See http://randspringer.de/boost for more documentation. Note that the error message suggests setting BOOST_ROOT. :-) However, looking in configure log, configure does not appear ever to have tried using -I$BOOST_ROOT when checking for Boost. This is a little confusing, because, as mentioned above, it appears that ax_boost_base.m4 is set up to try to use -I$BOOST_ROOT in the Boost CPP flags when testing for Boost. -- Boyce ------------------------------------------------------------------------------ Check out the vibrant tech community on one of the world's most engaging tech sites, SlashDot.org! http://sdm.link/slashdot _______________________________________________ Libmesh-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/libmesh-users
