tsuna / boost.m4 Goto Github PK
View Code? Open in Web Editor NEWM4 macros to use Boost with the autotools
Home Page: http://wiki.github.com/tsuna/boost.m4/
License: GNU General Public License v3.0
M4 macros to use Boost with the autotools
Home Page: http://wiki.github.com/tsuna/boost.m4/
License: GNU General Public License v3.0
,-------------------------------------------------. | ____ _ _ _ | | | __ ) ___ ___ ___| |_ _ __ ___ | || | | | | _ \ / _ \ / _ \/ __| __| | '_ ` _ \| || |_ | | | |_) | (_) | (_) \__ \ |_ _| | | | | |__ _| | | |____/ \___/ \___/|___/\__(_)_| |_| |_| |_| | | | `-------------------------------------------------' This package provides a set of M4 macros to use with GNU Autoconf. The purpose of these macros is to be able to easily find and test the various Boost libraries of a given version for a given compiler. This package is released under GPLv3+. This macro requires that you use GNU Libtool and assumes that you already use GNU Automake. If you don't already use Libtool, the step 3 below explains how to set it up. HOWTO ----- 1. If you have an invocation of AC_CONFIG_AUX_DIR in your configure.ac, then copy build-aux/boost.m4 in the directory specified by AC_CONFIG_AUX_DIR. Otherwise, copy the file at the root of your project. 2. In your top-level Makefile.am (this supposes that you use automake, which you most likely do) add: ACLOCAL_AMFLAGS = -I <dir> where `<dir>' is the (relative) path to the directory where you copied boost.m4 (set it to `.' if you put boost.m4 in the same, top-level directory). 3. If you don't use GNU Libtool already, then time has come to do the switch. Add AC_PROG_LIBTOOL to your configure.ac then, in all the Makefile.am of your project, change *_LIBRARIES to *_LTLIBRARIES (notice the extra `LT') for each of your library that depends on Boost. This way, Automake will delegate the build of your libraries to Libtool which will do the necessary magic so that you won't have to deal with LD_LIBRARY_PATH issues and so on. For programs however, you don't have anything special to do, Libtool will take care of them. 4. Then, add a call to BOOST_REQUIRE to your configure.ac as well as other calls to the various BOOST_* macros that check for the libraries you need. 5. Adjust your Makefile.am where you build targets that depend on Boost so that they use $(BOOST_CPPFLAGS), $(BOOST_*_LDFLAGS) and $(BOOST_*_LIBS) where appropriate (where `*' is the capitalized name of one of the libraries you checked for, e.g.: $(BOOST_THREAD_LDFLAGS)). E.g.: bin_PROGRAMS = foo foo_SOURCES = foo.cc foo_CPPFLAGS = $(BOOST_CPPFLAGS) foo_LDFLAGS = $(BOOST_THREAD_LDFLAGS) foo_LIBS = $(BOOST_THREAD_LIBS) Or if you have more than one target in the same Makefile.am and your targets don't have per-target specific flags (such as foo_LIBS) and you want all your targets to use the same set of Boost libraries, you can do the following instead: bin_PROGRAMS = foo bar foo_SOURCES = foo.cc bar_SOURCES = bar.cc AM_CPPFLAGS = $(BOOST_CPPFLAGS) AM_LDFLAGS = $(BOOST_THREAD_LDFLAGS) LIBS = $(BOOST_THREAD_LIBS) Remember that for targets that are programs, you must use LDADD or progname_LDADD, but for libraries you must use LIBS or libname_LIBS. MACROS ------ This section documents the various macros provided by boost.m4. BOOST_REQUIRE([VERSION]) ~~~~~~~~~~~~~~~~~~~~~~~~ The first, most important macro, is BOOST_REQUIRE. You should invoke it before other BOOST_* macros if you want to check that Boost has a minimum given version. Here are some examples: # Do not require any specific minimum version BOOST_REQUIRE # Require at least 1.34.1 BOOST_REQUIRE([1.34.1]) # Require a version number known at runtime BOOST_REQUIRE([$some_shell_variable]) This macro defines the Make symbol BOOST_CPPFLAGS. There are various predefined macros to check for common Boost libraries. They are ordered in two categories: the Boost libraries that are only made of headers, and the Boost libraries that (may) require linking to an installed library. Header-only Boost libraries ~~~~~~~~~~~~~~~~~~~~~~~~~~~ For each of the Boost libraries that are only made of headers, the macro to invoke is BOOST_<LIB-NAME> where <LIB-NAME> is the capitalized name of the library. Here is the list of libraries for which checks have been implemented: - Any - Array - Asio - Bimap - Bind - Cast - Conversion - CRC - Exception - Flyweight (with a dependency on pthread) - Foreach - Format - Function - Fusion - Geometry - Hash (aka Functional/Hash) - Iterator - Lambda - Math - MPL - MultiArray - MultiIndexContainer - NumericConversion - PointerContainer - Preprocessor - PropertyTree - Random - Ref - Signals2 - SmartPtr - StringAlgo - Tokenizer - Tribool - Tuple - Utility - Variant - Xpressive Thus you can invoke BOOST_FOREACH (for instance). It will check that <boost/foreach.hpp> works and define the preprocessor symbol HAVE_BOOST_FOREACH_HPP. For each of the libraries mentioned above, a couple of headers are checked (the most important ones) and preprocessor symbols are defined in an identical fashion. If the check fails, configure with abort with a fatal error. Boost libraries requiring linking ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For the other Boost libraries that (may) requiring linking to an installed library (shared or not), the macro to invoke is BOOST_<LIB-NAME> (surprise!) but this time the macro can take an optional argument to specify the runtime options you'd like to have. Most of the time, Boost libraries are compiled in several flavors, such as with or without debug, with a multi-thread runtime or not, etc. The macro will try to find a library that matches your requirements but may fall back to another flavor of the library if the one you asked for isn't available. The following libraries are supported: - Chrono - Context - Coroutine - Date_Time - Filesystem - Graph - IOStreams - Program_options - Regex - Serialization - Signals - System - Test (aka Unit Test Framework) - Thread - Wave Thus you can invoke BOOST_GRAPH (for instance) or BOOST_THREAD([mt-d]). The optional argument is made of one or more of the following letters: sgdpn (in that order) where: s = static runtime d = debug build g = debug/diagnostic runtime p = STLPort build n = (unsure) STLPort build without iostreams from STLPort (it looks like `n' must always be used along with `p'). Additionally, it can start with `mt-' to indicate that there is a preference for multi-thread builds. If the check is successful, at least one header has been checked and the corresponding preprocessor symbol HAVE_BOOST_*_HPP is defined, along with the compilation flags BOOST_<LIB-NAME>_LDFLAGS and BOOST_<LIB-NAME>_LIBS. Small pitfall: BOOST_TEST generates BOOST_UNIT_TEST_FRAMEWORK_LDFLAGS and BOOST_UNIT_TEST_FRAMEWORK_LIBS, not BOOST_TEST_LFDLAGS and BOOST_TEST_LIBS. Sorry for the inconsistency. NOTE: If you intend to use Wave/Spirit with thread support, make sure you call BOOST_THREAD first. Writing your own checks / supporting more Boost libraries ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ All the pre-existing library checks are written with help of BOOST_FIND_HEADER and BOOST_FIND_LIB. These two macros are very easy to use and are documented in boost.m4. Reading their documentation and reading the existing library checks should help you to easily write your own additional checks. Please contribute them to me by email to <tsuna at lrde.epita.fr>. You can checkout the Git source tree of this package at http://github.com/tsuna/boost.m4 Or simply download the latest version: wget http://github.com/tsuna/boost.m4/raw/master/build-aux/boost.m4 Patches welcome. LICENSE ------- The code of boost.m4 is released under GPLv3+ with the following additional clause: Additional permission under section 7 of the GNU General Public License, version 3 ("GPLv3"): If you convey this file as part of a work that contains a configuration script generated by Autoconf, you may do so under terms of your choice. This clause has been written by FSF lawyers for Autotools. If you have any concerns about legal issues, do not contact me as I Am Not A Lawyer. I *think* you can get advices at <copyright-clerk at fsf dot org>. The intent here is to keep the code Free but to allow anyone to *use* it.
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?
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) \
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
.
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.
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
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
for i in \
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
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
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
.
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.
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.
Hello,
Could it be possible to add support for boost.locale library.
Thanks
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:
Forgot to file this a few years ago and re-encountered it recently.
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
I've already written and tested the fix, I'll fork and send a pull request in the near future.
Travis runs clang 7, I can't reproduce the failures on clang 8 (with lld
8). Needs investigating!
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
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)
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.
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
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.
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_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.
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.
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
.
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
-lws2_32 was missing and was causing a linker error. (trying to use boost::asio which in turn was using boost::system)
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
Boost.m4 fails to link on OSX 10.7 with boost 1.49.0, but will work with boost 1.47.0.
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.
_BOOST_FIND_LIBS fails to find 64bit libs since it doesn't check the amd64|x86_64 sub dirs of */lib/
env: boost 1.59 (Solaris 11.3, gcc 4.8.2)
In 1.49 a dependency from thread to system library will be added.
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.
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 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
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?
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.
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
@@ -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"
@@ -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
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
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.
v0.1 is from 2008, it would be nice to have a new tag if possible.
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
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.
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
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.
Hello,
Could it be possible to add support for boost.locale library.
Thanks
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:
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]
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
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 to
boost::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 to
boost::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.
A declarative, efficient, and flexible JavaScript library for building user interfaces.
๐ Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. ๐๐๐
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google โค๏ธ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.