tsuna/boost.m4

M4 macros to use Boost with the autotools

boost.m4's Issues

Support boost.locale

Hello,

Could it be possible to add support for boost.locale library.

Thanks

OS X + boost::chrono fail.

Boost 1.54 is installed
GCC is 4.7.3

checking boost/chrono.hpp usability... yes
checking boost/chrono.hpp presence... yes
checking for boost/chrono.hpp... yes
checking for the Boost chrono library... configure: error: cannot compile a test that uses Boost chrono

configure:17816: checking boost/chrono.hpp usability
configure:17816: g++ -c -g -O2 -std=c++11 -I/orange/include conftest.cpp >&5
configure:17816: $? = 0
configure:17816: result: yes
configure:17816: checking boost/chrono.hpp presence
configure:17816: g++ -E -I/orange/include conftest.cpp
configure:17816: $? = 0
configure:17816: result: yes
configure:17816: checking for boost/chrono.hpp
configure:17816: result: yes
configure:17843: checking for the Boost chrono library
configure:17885: g++ -c -g -O2 -std=c++11 -I/orange/include conftest.cpp >&5
conftest.cpp: In function 'int main()':
conftest.cpp:42:1: error: 'thread_clock' is not a member of 'boost::chrono'
conftest.cpp:42:29: error: expected ';' before 'd'
configure:17885: $? = 1

BOOST_REQUIRE fails on Solaris due to hyphens in variable

I've had to patch around an issue using the boost.m4 file on Solaris. The sed command to extract the Boost version during the requirement check breaks and ends up with an empty version due to the use of hyphens in the macro.

I've found this patch works across platforms that I've tested by switching back to underscores:

http://git.shibboleth.net/view/?p=cpp-xmltooling.git;a=commitdiff;h=ad7702632e1a01c074f6ec15d2c0a937582be78c

Forgot to file this a few years ago and re-encountered it recently.

Boost MPI

Hello,
are there plans for Boost MPI support?

I've made a AX_BOOST_MPI macro that depends on AX_MPI and AX_BOOST_SERIALIZABLE, if someone is interested I can attach the code.

Keep up the good work.

some flags missing in msys-mingw environment

-lws2_32 was missing and was causing a linker error. (trying to use boost::asio which in turn was using boost::system)

Add collaborators to this repo?

Because you are probably too busy to maintain this code, maybe you can add a collaborator so that the project continues to be useful? There are many good PRs for this project that are waiting to be added and issues to be solved.

Github settings will let you add collaborators easily and it will ensure that your hard work remains useful.

Boost header version check fails with gcc 5.1

Output of configure:

checking for Boost's header version...
configure: error: invalid value: boost_major_version=

The boost.m4 code to extract the version number:

#include <boost/version.hpp>
boost-lib-version = BOOST_LIB_VERSION

The output will then be processed by sed.

The test fails as cpp seems to place a line marker between boost-lib-version = and the boost version string.

Output for cpp 4.9.2:

#1 "<stdin>"
#1 "<built-in>"
#1 "<command-line>"
#1 "/usr/include/stdc-predef.h" 1 3 4
#1 "<command-line>" 2
#1 "<stdin>"
#1 "/usr/include/boost/version.hpp" 1 3 4
#2 "<stdin>" 2
boost-lib-version = "1_55"

Output for cpp 5.1.0

#1 "<stdin>"
#1 "<built-in>"
#1 "<command-line>"
#1 "/usr/include/stdc-predef.h" 1 3 4
#1 "<command-line>" 2
#1 "<stdin>"
#1 "/usr/include/boost/version.hpp" 1 3 4
#2 "<stdin>" 2
boost-lib-version =
#2 "<stdin>" 3 4
                   "1_55"

The fix would be to use cpp -P to inhibit the generation of line markers.

No support for boost timer library

Hi,

Since boost 1.48 there is a new library: boost_timer. Would be great if boost.m4 could support it.

Thanks and best regards,
Sascha

Macros always add -R/usr/local/lib regardless of boost location

I have the following calls in in my configure.ac:

BOOST_REQUIRE
BOOST_BIND
BOOST_ASIO
BOOST_ARRAY
BOOST_SYSTEM
BOOST_THREADS
BOOST_SMART_PTR

And this results in -R/usr/local/lib being added to my compiler options even though my boost headers and libraries resides in /usr not /usr/local.

Fails to link Boost.Locale that needs dynamic iconv

The BOOST_LOCALE check fails when Boost.Locale was built dynamically linked against iconv. -liconv is then always required when linking with Boost.Locale, which boost.m4 doesn't seem to try.

problems with autoconf 2.59

Centos 5 has autoconf 2.59 and boost.m4 doesn't work there. The macros AC_PROG_GREP and AC_PROG_SED are not defined. If I remove those calls autoconf proceeds (albeit generating an invalid config file because GREP is not defined) but I get a warning:

configure:314: error: possibly undefined macro: BOOST_CPPFLAGS
      If this token and others are legitimate, please use m4_pattern_allow.
      See the Autoconf documentation.
configure:314: error: possibly undefined macro: BOOST_ROOT

ACTION-IF-NOT-FOUND with BOOST_FIND_LIB

I using BOOST_FIND_LIB to check for the availability of a library (regex in my case), but it is not an error for me if it is not present. Simply some feature of the software are not available. In the case where the library is not present, I simply want to set HAVE_BOOST_REGEX to false with AM_CONDITIONAL.

In other word, I am looking for something like this:

BOOST_CHECK_LIB([regex]) # set have_boost_regex to yes or no
AM_CONDITIONAL([HAVE_BOOST_REGEX], [test x"$have_boost_regex" = xyes])

Is there something equivalent with boost.m4?

CXXFLAGS mess on FreeBSD

The ports system on FreeBSD makes use of CXXFLAGS instead of CPPFLAGS. If you add CXXFLAGS=-I/usr/local/include boost detection will fail with the following error:
checking for Boost headers version >= 1.34.0... yes
checking for Boost's header version... BOOST_LIB_VERSION
configure: error: invalid value: boost_major_version=BOOSTLIB

If I remove it again, evertyhing boost related works just fine, but other header files can't be found.

I can work around this by setting --with-boost=/usr/local, but true autodetection of the headers and libraries would ofcourse be better.

If this could be fixed in a future release that would be awesome.

Best regards,

Ralf van der Enden

Static ('s') rtopt is ignored

Providing the 's' flag in BOOST_FIND_LIB's boost_rtopt argument is ignored causing shared-object library files to still be preferred.

In order to fix this, I propose changing line 388
case $boost_ldpath:$boost_rtopt_ in #(
to
case $boost_ldpath:$boost_rtopt in #(

Note that boost_rtopt_ is a temporary loop variable which is out of scope in this context.

Boost context checks are broken with Boost 1.58.0

PowerDNS recently had to stop using the BOOST_CONTEXT macro because the current test includes the Boost context 'all.hpp' header, which, in Boost 1.58.0, brings in a broken 'execution_context.hpp' header. This code depends on C++11, resulting in failure under some build configurations.

The context library test should reduce it's header check to just the 'fcontext.hpp' header file, which is all the current tests depend upon.

Related bug reports:

PowerDNS/pdns#3536

https://svn.boost.org/trac/boost/ticket/11223

Bug involving BOOST library detection when different BOOST versions are present

Hi, first of all thanks for your macros! I hope you're still reading these issues.

I think I found a bug with the way lib detection macros (such as BOOST_IOSTREAMS) work in the case when there exists a BOOST version (say, v1.46) installed in a standard location, but the user specifically asks for another version (newer, say v1.55) using BOOST_ROOT or --with-boost.

To check if a given library path /some/path contains a given library flavour such as boost_iostreams-mt, the BOOST_IOSTREAMS macro uses under the hood a command of the form:

g++ -o conftest -g -O2 -L/some/path conftest.o -lboost_iostreams-mt -lrt -lz

Unfortunately, this will succeed in the case when libboost_iostreams-mt.(a|so) exists in a standard location (/usr/lib/, v1.46), but not in the specific location where it is being searched for (/some/path, v1.55). It could be that /some/path only contains libboost_iostreams.(a|so), but not the -mt versions. The bug here is that the variables get set as follows:

BOOST_IOSTREAMS_LDFLAGS=-Wl,-R -Wl,/some/path -L/some/path
BOOST_IOSTREAMS_LIBS=-lboost_iostreams-mt

These are inconsistent. If one uses these variables in a Makefile, one gets linked against the old version from the standard directory despite of what _LDFLAGS suggests.

This scenario is not uncommon because the standard BOOST build instructions do not build -mt versions. Thus, people who want to use the latest version will generally end up without -mt libs, unless they know to ask for those.

I think the way to fix this issue is to use a full library name during the test only:

g++ -o conftest -g -O2 conftest.o /some/path/libboost_iostreams-mt.(a|so) -lrt -lz

This will prevent the test from succeeding by using a different file than expected. Once the test succeeds, the variable settings are ok. In my case, the test should succeed for /some/path/libboost_iostreams.(a|so), with _LIBS=-lboost_iostreams.

IMO, if the user specifies BOOST_ROOT and the requested library is not found under that path in any form, the check should either fail, or at least print a huge warning in blinking red that it is selecting a library version from a location other than the one specified, because chances are that wasn't what the user had in mind.

BOOST_THREAD(s) along with --with-boost=/path and --enable-static-boost tries to link with -lboost_thread-mt

I'm trying to link with static boost build and having a problem:

configure.ac

BOOST_REQUIRE([1.52.0])
BOOST_SYSTEM([s])
BOOST_THREADS([s])
BOOST_FOREACH
BOOST_PROGRAM_OPTIONS([s])
BOOST_ASIO([s])
BOOST_BIND

and run configure with

./configure --with-boost=/home/user/boost_1_58_0 --enable-static-boost

but linker fails generating the following error:

/bin/sh ../libtool --tag=CXX   --mode=link g++ -std=c++0x  -D LINUX -Wall -Wno-write-strings -I/home/user/boost_1_58_0 -g -O2 -static -L/home/user/boost_1_58_0/stage/lib -Wl,-R,/home/user/boost_1_58_0/stage/lib -L/home/user/boost_1_58_0/stage/lib -Wl,-R,/home/user/boost_1_58_0/stage/lib -L/home/user/boost_1_58_0/stage/lib -Wl,-R,/home/user/boost_1_58_0/stage/lib -o test1 /home/user/boost_1_58_0/stage/lib/libboost_system.a /home/user/boost_1_58_0/stage/lib/libboost_program_options.a -lboost_thread-mt /home/user/boost_1_58_0/stage/lib/libboost_system.a    -lrt 
libtool: link: g++ -std=c++0x -D LINUX -Wall -Wno-write-strings -I/home/user/boost_1_58_0 -g -O2 -Wl,-R -Wl,/home/user/boost_1_58_0/stage/lib -Wl,-R -Wl,/home/user/boost_1_58_0/stage/lib -Wl,-R -Wl,/home/user/boost_1_58_0/stage/lib -o test1 -L/home/user/boost_1_58_0/stage/lib /home/user/boost_1_58_0/stage/lib/libboost_program_options.a -lboost_thread-mt /home/user/boost_1_58_0/stage/lib/libboost_system.a -lrt
test1: In function `boost::thread::start_thread()':
/home/user/boost_1_58_0/boost/thread/detail/thread.hpp:179: undefined reference to `boost::thread::start_thread_noexcept()'
collect2: ld returned 1 exit status

Somehow -lboost_thread-mt linker flag is being used instead of static link with /home/user/boost_1_58_0/stage/lib/libboost_thread.a.

The host is CentOS 6.5 x64 2.6.32, i have also system Boost installed in /usr/local/lib

Non-fatal Boost detection failures

We want to provide support for conditional Boost support---in particular, we require Boost for one of our projects, but Boost threading is optionally supported. To support this, we've modified boost.m4's BOOST_FIND_LIB and BOOST_THREADS to run an optionally-provided ACTION-IF-NOT-FOUND (if not provided, the usual AC_MSG_ERROR behavior is retained). Patch follows in a comment. Thanks!

BOOST_REGEX FAILED (testsuite.at:297)

I edited the file testsuite.at file and changed line 297 to this:

AT_CHECK_MACRO([BOOST_REGEX (static)], [lib], [BOOST_PYTHON([s])])

This resolve the test failed error.

Jeff

boost.m4 check for boost_thread dependency for boost_context broken

The boost.m4 check for linking boost_thread to boost_context is incorrect, as this isn't linked where is available. The first release to change this behaviour is 1.61.0

Here's the relevant commit:
boostorg/context@01d3c90

Here's the relevant lines in the 1.71.0 release of boost_context:
https://github.com/boostorg/context/blob/boost-1.71.0/build/Jamfile.v2#L783-L789

--enable-static-boost and boost_filesystem

Hi,

As you know, after version 1.35.0 of Boost, there was an implicit link-time dependency between the Boost Filesystem module and the Boost System module. The current version of the boost.m4 checks for the Boost System Module if the Boost Filesystem Module is required. However, the BOOST_SYSTEM macro doesn't modify $BOOST_FILESYSTEM_LIBS. This works fine for dynamic linking: the '-R' option enables the linker to search for implicit link time dependencies without explicitly linking them. The problem is when a static link is requested using '--enable-static-boost'. Without the explicit addition of the libboost_system.a, anything linking against libboost_filesystem.a will fail like so:

In function __static_initialization_and_destruction_0': /home/radon01/ghall/local/boost_1_45_0/include/boost-1_45/boost/system/error_code.hpp:214: undefined reference toboost::system::generic_category()'
/home/radon01/ghall/local/boost_1_45_0/include/boost-1_45/boost/system/error_code.hpp:215: undefined reference to boost::system::generic_category()' /home/radon01/ghall/local/boost_1_45_0/include/boost-1_45/boost/system/error_code.hpp:216: undefined reference toboost::system::system_category()'

One possible solution is to detect if the static linking was requested, and if this is the case, to add the libboost_system.a to the list of $BOOST_FILESYSTEM_LIBS.

Thanks, boost.m4 is a great piece of work, and I appreciate all the hard work you've put into producing it.

Boost.m4 fails to link boost::thread for Boost version 1.49.0 on OSX

Boost.m4 fails to link on OSX 10.7 with boost 1.49.0, but will work with boost 1.47.0.

Mingw GCC-generated boost_thread libraries do not have _win32 suffix in version 4.8.1

The current version of boost.m4 assumes that versions of boost_thread generated by Mingw are called boost_thread_win32. This is not true with Mingw GCC 4.8.1, which calls them libboost_thread. I am not sure when this change occurred though.

As a result, autoconf fails to detect them even though they are present.

-lboost_thread missing (Linux)

The BOOST_THREAD_LDFLAGS variable is missing the -lboost_thread flag on Linux, which is required to link newer boost::threads library.

Suggested solution: Append " -lboost_thread" to line 914 (but I am not sure whether this works, it's not tested)

BOOST_CHRONO is missing

I've already written and tested the fix, I'll fork and send a pull request in the near future.

new tag?

v0.1 is from 2008, it would be nice to have a new tag if possible.

Add support to GCC 4.6

This patch was originally submitted to Gnote:
https://bugzilla.gnome.org/show_bug.cgi?id=641416

From 46a97bf9ab0447e8aa958c147cf80fa9e0725f9c Mon Sep 17 00:00:00 2001
From: Bastien Nocera [email protected]
Date: Thu, 3 Feb 2011 23:26:12 +0000
Subject: [PATCH] Add test for GCC 4.6

As used in Fedora 15

build-aux/boost.m4 | 1 +
1 files changed, 1 insertions(+), 0 deletions(-)

diff --git a/build-aux/boost.m4 b/build-aux/boost.m4
index 3d271f6..f02f102 100644
--- a/build-aux/boost.m4
+++ b/build-aux/boost.m4
@@ -952,6 +952,7 @@ if test x$boost_cv_inc_path != xno; then

I'm not sure about my test for `il' (be careful: Intel's ICC pre-defines

the same defines as GCC's).

for i in \

• _BOOST_gcc_test(4, 6)
  _BOOST_gcc_test(4, 5)
  _BOOST_gcc_test(4, 4)
  _BOOST_gcc_test(4, 3)
  --
  1.7.4

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

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

fix for boost::thread >1.54

Hallo,
boost::thread needs to link against boost::atomic since 1.54.
The attached patch (should) fix this.

Thanks!

diff --git a/m4/boost.m4 b/m4/boost.m4
index c8eb65a..0af5bbf 100644
--- a/m4/boost.m4
+++ b/m4/boost.m4
@@ -737,7 +737,15 @@ BOOST_DEFUN([Program_Options],
                 [boost::program_options::options_description d("test");])
 ])# BOOST_PROGRAM_OPTIONS
## 

+# BOOST_ATOMIC([PREFERRED-RT-OPT])
+# -----------------------------------------
+# Look for Boost.Atomic.  For the documentation of PREFERRED-RT-OPT,
+# see the documentation of BOOST_FIND_LIB above.
+BOOST_DEFUN([Atomic],
+[BOOST_FIND_LIB([atomic], [$1],
-                [boost/atomic.hpp],
- ```
             [boost::atomic<bool> done (false);])

+])# BOOST_ATOMIC

_BOOST_PYTHON_CONFIG(VARIABLE, FLAG)

------------------------------------

@@ -885,8 +893,13 @@ if test $boost_major_version -ge 149; then
BOOST_SYSTEM([$1])
fi # end of the Boost.System check.
m4_pattern_allow([^BOOST_SYSTEM_(LIBS|LDFLAGS)$])dnl
-LIBS="$LIBS $BOOST_SYSTEM_LIBS $boost_cv_pthread_flag"
-LDFLAGS="$LDFLAGS $BOOST_SYSTEM_LDFLAGS"
+# At least on some archs, link-time dependency from thread to atomic was added as of 1.54
+if test $boost_major_version -ge 154; then
+BOOST_ATOMIC([$1])
+fi # end of the Boost.Atomic check.
+m4_pattern_allow([^BOOST_ATOMIC_(LIBS|LDFLAGS)$])dnl
+LIBS="$LIBS $BOOST_SYSTEM_LIBS $BOOST_ATOMIC_LIBS $boost_cv_pthread_flag"
+LDFLAGS="$LDFLAGS $BOOST_SYSTEM_LDFLAGS $BOOST_ATOMIC_LDFLAGS"

Yes, we need to put the -pthread thing in CPPFLAGS because with GCC3,

boost/thread.hpp will trigger a #error if -pthread isn't used:

boost/config/requires_threads.hpp:47:5: #error "Compiler threading support

@@ -910,8 +923,8 @@ case $host_os in
;;
esac

-BOOST_THREAD_LIBS="$BOOST_THREAD_LIBS $BOOST_SYSTEM_LIBS $boost_cv_pthread_flag"
-BOOST_THREAD_LDFLAGS="$BOOST_SYSTEM_LDFLAGS"
+BOOST_THREAD_LIBS="$BOOST_THREAD_LIBS $BOOST_SYSTEM_LIBS $BOOST_ATOMIC_LIBS $boost_cv_pthread_flag"
+BOOST_THREAD_LDFLAGS="$BOOST_SYSTEM_LDFLAGS $BOOST_ATOMIC_LDFLAGS"
BOOST_CPPFLAGS="$BOOST_CPPFLAGS $boost_cv_pthread_flag"
LIBS=$boost_threads_save_LIBS
LDFLAGS=$boost_threads_save_LDFLAGS

BOOST_PYTHON custom python 2.7, and Mac OSX issue.

Excuse my lack of knowledge on autoconf/m4, and it is entirely possible that I am simply doing something wrong, but I've been trying to troubleshoot this for a while, and think it might be a bug.

I am including the following boost.m4 statements in my configure.ac file:

BOOST_REQUIRE
BOOST_MATH
BOOST_PYTHON

BOOST_REQUIRE and BOOST_MATH are working fine. With BOOST_PYTHON, I see the following when I ./configure:

checking for Boost's header version... 1_46_1
checking boost/math/special_functions.hpp usability... yes
checking boost/math/special_functions.hpp presence... yes
checking for boost/math/special_functions.hpp... yes
checking for the toolset name used by Boost for g++... xgcc42 -xgcc
checking boost/python.hpp usability... yes
checking boost/python.hpp presence... yes
checking for boost/python.hpp... yes
checking for the Boost python library... no
configure: error: cannot find the flags to link with Boost python

Looking in configure.log, I see:

configure:16023: checking boost/python.hpp usability
configure:16023: g++ -c -g -O2  -I/Library/Frameworks/Python.framework/Versions/2.7/include/python2.7 -I/Library/Frameworks/Python.framework/Versions/2.7/include/python2.7  conftest.cpp >&5
configure:16023: $? = 0
configure:16023: result: yes
configure:16023: checking boost/python.hpp presence
configure:16023: g++ -E  -I/Library/Frameworks/Python.framework/Versions/2.7/include/python2.7 -I/Library/Frameworks/Python.framework/Versions/2.7/include/python2.7  conftest.cpp
configure:16023: $? = 0
configure:16023: result: yes
configure:16023: checking for boost/python.hpp
configure:16023: result: yes
configure:16050: checking for the Boost python library
configure:16092: g++ -c -g -O2  -I/Library/Frameworks/Python.framework/Versions/2.7/include/python2.7 -I/Library/Frameworks/Python.framework/Versions/2.7/include/python2.7  conftest.cpp >&5
configure:16092: $? = 0
configure:16143: re-using the existing conftest.o
configure:16149: g++ -o conftest -g -O2  -I/Library/Frameworks/Python.framework/Versions/2.7/include/python2.7 -I/Library/Frameworks/Python.framework/Versions/2.7/include/python2.7   -L/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/config -ldl -framework CoreFoundation -lpython2.7 -u _PyMac_Error Python.framework/Versions/2.7/Python -L/opt/local/lib conftest.o -lboost_python-xgcc42-mt-1_46_1  -ldl -framework CoreFoundation -lpython2.7 >&5
i686-apple-darwin10-g++-4.2.1: Python.framework/Versions/2.7/Python: No such file or directory
configure:16158: $? = 1

(It tries a bunch of other directories). The issues I see is -u _PyMac_Error Python.framework/Versions/2.7/Python I'm not exactly sure where this is coming from, but it doesn't look right. Thoughts?

1.49 introduces dependency from thread to system (includes patch)

In 1.49 a dependency from thread to system library will be added.

(See
http://boost.2283326.n4.nabble.com/thread-Can-t-use-boost-thread-mutex-hpp-without-boost-system-td4306342.html )

I created a patch to boost.m4 by copy and pasting from boost filesystem. It works fine for me with 1.49 (= boost trunk) and versions released before.

Need -pthread on some platforms if using an asio tcp_resolver

I have found out the hard way that the following code:

boost::asio::io_service io_service;
boost::asio::ip::tcp::resolver r(io_service);

will not link unless the -pthread flag is given on some platforms (at least FreeBSD and CentOS 7).

I am working around this with the following addition to boost.m4:

BOOST_ASIO_RESOLVER()

---------------------

tcp resolver requires the pthread flag for linking

BOOST_DEFUN([Asio_Resolver],
[AC_REQUIRE([_BOOST_PTHREAD_FLAG])
AC_SUBST([BOOST_ASIO_RESOLVER_LIBS], [$boost_cv_pthread_flag])
])

This allows me to set LDFLAGS (or libs) for programs that are using the resolver so they link correctly. Not sure if there is a better way to do this, but it solves the problem for me.

Use -Wl,-R instead of -R

For compatibility with GCC 4.6.
Also submitting this to:
https://bugzilla.gnome.org/show_bug.cgi?id=641416

--- ../gnote/m4/boost.m4    2011-01-25 14:30:18.000000000 +0200
+++ m4/boost.m4 2011-02-27 20:57:11.686221539 +0200
@@ -403,7 +403,7 @@
       LDFLAGS=$boost_save_LDFLAGS
       LIBS=$boost_save_LIBS
       if test x"$Boost_lib" = xyes; then
-        Boost_lib_LDFLAGS="-L$boost_ldpath -R$boost_ldpath"
+        Boost_lib_LDFLAGS="-L$boost_ldpath -Wl,-R$boost_ldpath"
         Boost_lib_LDPATH="$boost_ldpath"
         break 6
       else

Support boost.locale

Hello,

Could it be possible to add support for boost.locale library.

Thanks

BOOST_PYTHON error since python 3.8

Since python 3.8, "python3-config --libs" doesn't return -lpython3.8. So the macro BOOST_PYTHON fail with the following stack trace:
configure:15049: g++ -o conftest -O3 -std=c++14 -DNDEBUG -I/usr/include/python3.8 -I/usr/include/python3.8 -L/usr/lib -lcrypt -lpthread -ldl -lutil -lm -lm -L/lib64 conftest.o -lboost_python3 -lcrypt -lpthread -ldl -lutil -lm -lm >&5 /usr/bin/ld: conftest.o: in function boost::python::api::slice_nil::~slice_nil()':
conftest.cpp:(.text._ZN5boost6python3api9slice_nilD2Ev[_ZN5boost6python3api9slice_nilD5Ev]+0x15): undefined reference to _Py_Dealloc' /usr/bin/ld: conftest.o: in function _GLOBAL__sub_I_PyInit_empty':
conftest.cpp:(.text.startup+0x13): undefined reference to _Py_NoneStruct' /usr/bin/ld: conftest.cpp:(.text.startup+0x1b): undefined reference to _Py_NoneStruct'
/usr/bin/ld: /usr/lib/libboost_python3.so: undefined reference to PyExc_ValueError' /usr/bin/ld: /usr/lib/libboost_python3.so: undefined reference to PyLong_AsLong'
(…)`

Full config.log

Boost.Containers compatibility

http://www.boost.org/doc/libs/1_56_0/doc/html/container.html#container.intro

there doesn't appear to be a main header, they're all in a subdirectory, and I can't find any portion of your m4 file thats delegated to dealing with these.

Support boost::random and libboost-random

I was trying to use boost::random::random_device, and when linking got a linker error. Apparently I need to link with libboost-random. But these macros don't support it.

So I guess it would be great to have a BOOST_RANDOM macro to link with libboost-random.

iostreams check will not work in future boost releases - including short-term patch

It seems that boost::iostreams changed its constructors, so the
current boost.m4 test is no longer intended to work in future boost
releases:

see https://svn.boost.org/trac/boost/ticket/4460

I tried to find away around boost::filesystem, but the smallest test I
could find is the following, which requires to link against
libboost_filesystem as well as libboost_iostreams:

#include <boost/filesystem/path.hpp>
#include <boost/iostreams/device/file_descriptor.hpp>

int
main ()
{
 boost::filesystem::path p;
 boost::iostreams::file_descriptor fd(p);
 fd.close();
 return 0;
}

A nasty possibility would be to use a preprocessor directive to enable deprectated boost features. This possibility provides an easy patch but I guess it is no long-term solution.

Here is the patch (currently stored in the "dlvhex" sourcefore repo, so don't look at revision numbers):

Index: m4/boost.m4
=================================================================
--- m4/boost.m4 (revision 2297)
+++ m4/boost.m4 (revision 2300)
@@ -541,9 +541,12 @@
 # Look for Boost.IOStreams.  For the documentation of PREFERRED-RT-OPT, see the
 # documentation of BOOST_FIND_LIB above.
 AC_DEFUN([BOOST_IOSTREAMS],
-[BOOST_FIND_LIB([iostreams], [$1],
+[boost_iostreams_save_CPPFLAGS=$CPPFLAGS
+CPPFLAGS="$CPPFLAGS -DBOOST_IOSTREAMS_USE_DEPRECATED"
+BOOST_FIND_LIB([iostreams], [$1],
                 [boost/iostreams/device/file_descriptor.hpp],
                 [boost::iostreams::file_descriptor fd(0); fd.close();])
+CPPFLAGS=$boost_iostreams_save_CPPFLAGS
 ])# BOOST_IOSTREAMS

This short-term patch also works with older versions of boost.

Best,
Peter

Travis testsuite fails with clang

Travis runs clang 7, I can't reproduce the failures on clang 8 (with lld 8). Needs investigating!

Incorrect tags when Mingw GCC 4.8.1 is used.

boost.m4 looks for libraries tagged libboost_XXX-gcc48.so or such because it fails to recognize Mingw flavor. I will post a patch soon.

Favor linking against non-versioned shared object.

Suppose that /usr/lib has:

libboost_regex.so -> libboost_regex.so.1.55.0
libboost_regex.so.1.55.0

BOOST_REGEX will set BOOST_REGEX_LIBS to libboost_regex.so.1.55.0, which in turns creates a dependency from the binary to a very specific version of boost.

BOOST_REGEX_LIBS should be set to libboost_regex.so so that the binary can be used with different versions of boost. It is the package maintainer's job to ensure that the system's runtime loads one of the correct version of boost.

BOOST_LDPATH not set on 64bits Debian multiarch

Greetings,

I am reporting that boost.m4 does not seem to fill-in the following variables
when run on a Debian GNU/Linux box:

BOOST_CHRONO_LDFLAGS =
BOOST_CHRONO_LDPATH =
BOOST_CHRONO_LIBS = -lboost_chrono
BOOST_CPPFLAGS = -pthread
BOOST_DATE_TIME_LDFLAGS =
BOOST_DATE_TIME_LDPATH =
BOOST_DATE_TIME_LIBS = -lboost_date_time
BOOST_FILESYSTEM_LDFLAGS =
BOOST_FILESYSTEM_LDPATH =
BOOST_FILESYSTEM_LIBS = -lboost_filesystem
BOOST_IOSTREAMS_LDFLAGS =
BOOST_IOSTREAMS_LDPATH =
BOOST_IOSTREAMS_LIBS = -lboost_iostreams
BOOST_LDPATH =
BOOST_LIBS_DIR =
BOOST_PROGRAM_OPTIONS_LDFLAGS =
BOOST_PROGRAM_OPTIONS_LDPATH =
BOOST_PROGRAM_OPTIONS_LIBS = -lboost_program_options
BOOST_REGEX_LDFLAGS =
BOOST_REGEX_LDPATH =
BOOST_REGEX_LIBS = -lboost_regex
BOOST_ROOT =
BOOST_SERIALIZATION_LDFLAGS =
BOOST_SERIALIZATION_LDPATH =
BOOST_SERIALIZATION_LIBS = -lboost_serialization
BOOST_SYSTEM_LDFLAGS =
BOOST_SYSTEM_LDPATH =
BOOST_SYSTEM_LIBS = -lboost_system
BOOST_THREAD_LDFLAGS =
BOOST_THREAD_LDPATH =
BOOST_THREAD_LIBS = -lboost_thread -lboost_system -pthread

What the test shows is that when trying to find header files, everything is ok.
BUT, each time the test tries to locate the library, it fails. I guess this is
because in my Debian box, the headers are in /usr/include, while the libs are
in /usr/lib/x86_64-linux-gnu, which is not tested, apparently, as a potential
location for libs. However the -l switch is created fine because my understanding is that the macro tries a link, and the system itself obviously knows where to find the libs (namely in /usr/lib/x86_64-linux-gnu).

gcc -print-multiarch provides just this: x86_64-linux-gnu, so I wonder if, to
make the macros compatible with Debian and Ubuntu (they have not adopted the
standard that RedHat has), we should not try to get that potential lib path
using it dynamically.

Are my assumptions correct? If so can we expect a fix? I really have little
knowledge in autotools, otherwise I would try to make a patch. Sorry.
Sincerely,
Filippo Rusconi [email protected]

boost.m4 fails on Solaris and his (freeware open source) derivatives.

PowerDNS/pdns@4c8049e#commitcomment-13086287

_BOOST_FIND_LIBS doesn't honor 64bit libs

_BOOST_FIND_LIBS fails to find 64bit libs since it doesn't check the amd64|x86_64 sub dirs of */lib/

if defined(__amd64) || defined(__x86_64)

env: boost 1.59 (Solaris 11.3, gcc 4.8.2)

No -R in MacOS X's ld

Spawned off from here:

MacOS X's ld64-97.17 doesn't understand -R<dir>, thus -Wl,-R in BOOST_FIND_LIB() fails. Instead, it wants -rpath <dir>. That also works with GNU ld 2.21.0; however, I'm unsure about its portability.

The GNU ld manpage does seem to suggest that -R on a directory is only a compatibility option, and -rpath would be more correct:

For compatibility with other ELF linkers, if the -R option is followed by a
directory name, rather than a file name, it is treated as the -rpath option.

However, it also suggest that -rpath=<dir> (note the = instead of a space) would be correct, but that's also rejected by MacOS X's ld.

boost_cv_pthread_flag= gets never set

On Solaris with boost 1.59 and gcc 4.8.2 'boost_cv_pthread_flag' gets never set and thus thread tests fail (testing target http://cvc4.cs.nyu.edu/builds/src/unstable/).

Using this workaround for now (sufficient for g++):

AC_DEFUN([_BOOST_PTHREAD_FLAG],
[AC_REQUIRE([AC_PROG_CXX])dnl
AC_REQUIRE([AC_CANONICAL_HOST])dnl
AC_LANG_PUSH([C++])dnl
AC_CACHE_CHECK([for the flags needed to use pthreads], [boost_cv_pthread_flag],
[ boost_cv_pthread_flag=-pthreads ])
AC_LANG_POP([C++])dnl
])# _BOOST_PTHREAD_FLAG

Add support to GCC 4.6

Closed previous by accident...

Original patch is from here:
https://bugzilla.gnome.org/show_bug.cgi?id=641416

Sorry for format... Follow the link above for a proper patch.

diff --git a/build-aux/boost.m4 b/build-aux/boost.m4
index 3d271f6..f02f102 100644
--- a/build-aux/boost.m4
+++ b/build-aux/boost.m4
@@ -952,6 +952,7 @@ if test x$boost_cv_inc_path != xno; then
   # I'm not sure about my test for `il' (be careful: Intel's ICC pre-defines
   # the same defines as GCC's).
   for i in \
+    _BOOST_gcc_test(4, 6) \
     _BOOST_gcc_test(4, 5) \
     _BOOST_gcc_test(4, 4) \
     _BOOST_gcc_test(4, 3) \

Boost context checks are broken with Boost 1.68.0

The current test checks for the presence of fcontext.hpp header under boost/context. The header has been made private two years ago, so it resides under boost/context/detail.