when --with-boost is provided only libs in the given path should be checked

[jin-eld]

As a comment in code says it should work like this: # If the user provided a value to --with-boost, use it and only it.

It does work for header checks, however, this does not seem to be the case for library checks. Even if --with-boost is set, the macros still try to add -L/usr/local:

Here is a sniplet from config.log when searching for boost_system, first attempt is correct, but instead of going on with -L combinations it should already skip to trying other library names, because --with-boos option was specified.

configure:17734: arm-angstrom-linux-gnueabi-g++ -march=armv5te -mno-thumb -mthumb-interwork -mtune=arm926ej-s -mthumb-interwork -mno-thumb --sysroot=/oe/jin/dss-oe/angstrom-devel-build-eglibc/sysroots/at91sam9g20ek -o conftest -O2 -pipe -g -feliminate-unused-debug-types -fpermissive -fvisibility-inlines-hidden -fvisibility-inlines-hidden -I/oe/jin/dss-oe/angstrom-devel-build-eglibc/sysroots/at91sam9g20ek/usr/include -Wl,-O1 -Wl,--hash-style=gnu -Wl,--as-needed -L/oe/jin/dss-oe/angstrom-devel-build-eglibc/sysroots/at91sam9g20ek/usr/lib conftest.o -lboost_system-gcc45-mt-1_47 >&5 /oe/jin/dss-oe/angstrom-devel-build-eglibc/sysroots/x86_64-linux/usr/libexec/armv5te-angstrom-linux-gnueabi/gcc/arm-angstrom-linux-gnueabi/4.5.4/ld: cannot find -lboost_system-gcc45-mt-1_47 collect2: ld returned 1 exit status configure:17743: $? = 1 configure:17728: re-using the existing conftest.o configure:17734: arm-angstrom-linux-gnueabi-g++ -march=armv5te -mno-thumb -mthumb-interwork -mtune=arm926ej-s -mthumb-interwork -mno-thumb --sysroot=/oe/jin/dss-oe/angstrom-devel-build-eglibc/sysroots/at91sam9g20ek -o conftest -O2 -pipe -g -feliminate-unused-debug-types -fpermissive -fvisibility-inlines-hidden -fvisibility-inlines-hidden -I/oe/jin/dss-oe/angstrom-devel-build-eglibc/sysroots/at91sam9g20ek/usr/include -Wl,-O1 -Wl,--hash-style=gnu -Wl,--as-needed -L/usr/local/lib conftest.o -lboost_system-gcc45-mt-1_47 >&5 /oe/jin/dss-oe/angstrom-devel-build-eglibc/sysroots/x86_64-linux/usr/libexec/armv5te-angstrom-linux-gnueabi/gcc/arm-angstrom-linux-gnueabi/4.5.4/ld: warning: library search path "/usr/local/lib" is unsafe for cross-compilation /oe/jin/dss-oe/angstrom-devel-build-eglibc/sysroots/x86_64-linux/usr/libexec/armv5te-angstrom-linux-gnueabi/gcc/arm-angstrom-linux-gnueabi/4.5.4/ld: cannot find -lboost_system-gcc45-mt-1_47 collect2: ld returned 1 exit status configure:17743: $? = 1

This patch seems to solve the problem for me:

diff --git a/build-aux/boost.m4 b/build-aux/boost.m4
index b1cb1b1..843df28 100644
--- a/build-aux/boost.m4
+++ b/build-aux/boost.m4
@@ -376,11 +376,12 @@ for boost_rtopt_ in $boost_rtopt '' -d; do
     esac
     # If with_boost is empty, we'll search in /lib first, which is not quite
     # right so instead we'll try to a location based on where the headers are.
-    boost_tmp_lib=$with_boost
-    test x"$with_boost" = x && boost_tmp_lib=${boost_cv_inc_path%/include}
-    for boost_ldpath in "$boost_tmp_lib/lib" '' \
-             /opt/local/lib* /usr/local/lib* /opt/lib* /usr/lib* \
-             "$with_boost" C:/Boost/lib /lib*
+    boost_tmp_lib=$with_boost/lib
+    test x"$with_boost" = x && boost_tmp_lib="${boost_cv_inc_path%/include} \
+        /opt/local/lib* /usr/local/lib* /opt/lib* /usr/lib* \
+        "$with_boost" C:/Boost/lib /lib*"
+
+    for boost_ldpath in $boost_tmp_lib
     do
       test -e "$boost_ldpath" || continue
       boost_save_LDFLAGS=$LDFLAGS

[joshuaimmanuel]

The patch doesn't check for with_sysroot. So, to address this, I've included my patch for the benefit of others

diff --git a/boost.m4 b/boost.m4
index b1cb1b1..716a477 100644
--- a/boost.m4
+++ b/boost.m4
@@ -374,13 +374,27 @@ for boost_rtopt_ in $boost_rtopt '' -d; do
     case $boost_failed_libs in #(
       *@$boost_lib@*) continue;;
     esac
-    # If with_boost is empty, we'll search in /lib first, which is not quite
-    # right so instead we'll try to a location based on where the headers are.
-    boost_tmp_lib=$with_boost
-    test x"$with_boost" = x && boost_tmp_lib=${boost_cv_inc_path%/include}
-    for boost_ldpath in "$boost_tmp_lib/lib" '' \
-             /opt/local/lib* /usr/local/lib* /opt/lib* /usr/lib* \
-             "$with_boost" C:/Boost/lib /lib*
+    # If with_boost is empty, we'll search in /lib first, which is not
+    # quite right so instead we'll try to a location based on where
+    # the headers are.  If with_sysroot is specified then we prepend
+    # with_sysroot path to the boost_tmp_lib variable
+    if [[ -z ${with_sysroot+xxx} ]]; then
+       # with_sysroot variable not set at all
+      boost_tmp_lib=${with_boost}/lib
+      test x"$with_boost" = x && boost_tmp_lib="${boost_cv_inc_path%/include} \
+           /opt/local/lib* /usr/local/lib* /opt/lib* /usr/lib* \
+           ${with_boost} C:/Boost/lib /lib*"
+    else
+      boost_tmp_lib="${with_sysroot}/${boost_cv_inc_path%/include} \
+                  ${with_sysroot}/opt/local/lib* \
+                  ${with_sysroot}/usr/local/lib* \
+                  ${with_sysroot}/lib* \
+                  ${with_sysroot}/usr/lib* \
+                  ${with_sysroot}/opt/lib* \
+                  ${with_sysroot}/Boost/lib ${with_boost}"
+    fi
+
+    for boost_ldpath in $boost_tmp_lib
     do
       test -e "$boost_ldpath" || continue
       boost_save_LDFLAGS=$LDFLAGS
@@ -1107,11 +1121,11 @@ boost_use_source=:
 test -f conftest.$ac_objext && ac_ext=$ac_objext && boost_use_source=false &&
   _AS_ECHO_LOG([re-using the existing conftest.$ac_objext])
 AS_IF([_AC_DO_STDERR($ac_link) && {
-    test -z "$ac_[]_AC_LANG_ABBREV[]_werror_flag" ||
-    test ! -s conftest.err
+        test -z "$ac_[]_AC_LANG_ABBREV[]_werror_flag" ||
+        test ! -s conftest.err
        } && test -s conftest$ac_exeext && {
-    test "$cross_compiling" = yes ||
-    $as_executable_p conftest$ac_exeext
+        test "$cross_compiling" = yes ||
+        $as_executable_p conftest$ac_exeext
 dnl FIXME: use AS_TEST_X instead when 2.61 is widespread enough.
        }],
       [$2],

[joshuaimmanuel]

will have to think on what to do if both with_sysroot and with_boost option is given

[stephanmehlhase]

I have a somewhat related issue: I provide a path to --with-boost which does not contain the -mt libraries, however, the script does select the -mt libraries of an older version which are installed in the system (which I explicitely do not want to use because they are too old). I tried applying the patch, but even with the patch it does not seem to work right. This is the relevant snippet from config.log:

configure:16671: re-using the existing conftest.o
configure:16677: g++ -o conftest -g -O2 -std=c++11  -pthread -I/home/stephan/libs/boost-1.53/include  -L/home/stephan/libs/boost-1.53 -Wl,-R/home/stephan/libs/boost-1.53 -L/home/stephan/libs/boost-1.53 conftest.o -lboost_thread-mt  -lboost_system-mt -pthread >&5
configure:16686: $? = 0
configure:16726: result: yes

It results to yes even though /home/stephan/libs/boost-1.53/lib does only include libboost_thread.so not the -mt variant.

[benkirk]

I have precisely the same issue on my CentOS 6.3 install. The OS provides -mt variants in /usr/lib64, I have newer libs in $BOOST_ROOT that do not contain -mt, yet the -mt variant is chosen:

BOOST_REQUIRE([1.36])
BOOST_TEST

ultimately produces

   Link with Boost............ : yes
      BOOST_CPPFLAGS.......... : -I/software/x86_64/boost/1.53.0-gcc-4.6/include
      Boost LIBS.............. : -L/software/x86_64/boost/1.53.0-gcc-4.6/lib -Wl,-R,/software/x86_64/boost/1.53.0-gcc-4.6/lib -lboost_unit_test_framework-mt

which erroneously brings in the older, OS provided versions:

benkirk(10)$ ll /software/x86_64/boost/1.53.0-gcc-4.6/lib/*boost_unit_test_framework-mt*
ls: cannot access /software/x86_64/boost/1.53.0-gcc-4.6/lib/*boost_unit_test_framework-mt*: No such file or directory

benkirk(11)$ ll /usr/lib64/*boost_unit_test_framework-mt*
lrwxrwxrwx. 1 root root     36 Nov  1  2011 /usr/lib64/libboost_unit_test_framework-mt.so -> libboost_unit_test_framework-mt.so.5
-rwxr-xr-x. 1 root root 774904 Sep 23  2011 /usr/lib64/libboost_unit_test_framework-mt.so.5

What's the right fix for this situation?

[benkirk]

Apparently part of this confusion is because ./b2 defaults to the --layout=system on Unix for recent installs. Building with --layout=tagged adds the -mt extension on the installed libraries:

./b2 --help
...
--layout=<layout>       Determines whether to choose library names
                          and header locations such that multiple
                          versions of Boost or multiple compilers can
                          be used on the same system.

                              versioned - Names of boost binaries
                              include the Boost version number, name and
                              version of the compiler and encoded build
                              properties.  Boost headers are installed in a
                              subdirectory of <HDRDIR> whose name contains
                              the Boost version number.

                              tagged -- Names of boost binaries include the
                              encoded build properties such as variant and
                              threading, but do not including compiler name
                              and version, or Boost version. This option is
                              useful if you build several variants of Boost,
                              using the same compiler.

                              system - Binaries names do not include the
                              Boost version number or the name and version
                              number of the compiler.  Boost headers are
                              installed directly into <HDRDIR>.  This option
                              is intended for system integrators who are
                              building distribution packages.

                          The default value is 'versioned' on Windows, and
                          'system' on Unix.

So when I build boost with something like

./bootstrap.sh --prefix=/software/x86_64/boost/$boost_version-$COMPILER_ID_STRING --with-toolset=$build_toolset
./b2 --prefix=/software/x86_64/boost/$boost_version-$COMPILER_ID_STRING install threading=single,multi --layout=tagged -j12

I at least get the -mt label on my installed libs, which may provide a workaround for you, @stephanmehlhase.

[jrandall]

This issue is affecting me as well. It seems that Boost installed in a separate prefix (alongside a system installed Boost) that is built with the default options as of the current version (i.e. --layout=system) does not work with boost.m4 for dynamically linked Boost library because it ends up hardcoding a versioned library dependency on the version installed in the system rather than in the given --with-boost prefix. This is very frustrating.

I guess I have no choice but to install yet another version of Boost, this time using --layout=tagged just to make boost.m4 happy. Ugh.

[eyal0]

This PR claims to fix the issue:

https://github.com/tsuna/boost.m4/pull/82

[djerius]

I've updated PR #82 with a rebase against master and a couple of bug fixes.