Hi folks,
[I've posted this to both user and development lists, because I'm not
sure which is most appropriate in this case.]
I make use of several Boost libraries in my schroot program
(svn://svn.debian.org/svn/buildd-tools/trunk/schroot).
This project, like many, utilises GNU Autoconf and Automake for its
build system. I need to determine how to link with the Boost
libraries in order to build the programs in the project. This is an
issue for many projects which want to link with a Boost library.
To illustrate my problem:
ls -l /usr/lib/libboost_regex-*.so /usr/lib/libboost_program_options-*.so
lrwxrwxrwx 1 root root 45 2007-07-08 11:48 /usr/lib/libboost_program_options-gcc41-1_34.so -> libboost_program_options-gcc41-1_34.so.1.34.0
lrwxrwxrwx 1 root root 48 2007-07-08 11:48 /usr/lib/libboost_program_options-gcc41-mt-1_34.so -> libboost_program_options-gcc41-mt-1_34.so.1.34.0
lrwxrwxrwx 1 root root 41 2007-07-08 11:48 /usr/lib/libboost_program_options-mt.so -> libboost_program_options-gcc41-mt-1_34.so
lrwxrwxrwx 1 root root 38 2007-07-08 11:48 /usr/lib/libboost_program_options-st.so -> libboost_program_options-gcc41-1_34.so
lrwxrwxrwx 1 root root 35 2007-07-08 11:47 /usr/lib/libboost_regex-gcc41-1_34.so -> libboost_regex-gcc41-1_34.so.1.34.0
lrwxrwxrwx 1 root root 38 2007-07-08 11:47 /usr/lib/libboost_regex-gcc41-mt-1_34.so -> libboost_regex-gcc41-mt-1_34.so.1.34.0
lrwxrwxrwx 1 root root 31 2007-07-08 11:47 /usr/lib/libboost_regex-mt.so -> libboost_regex-gcc41-mt-1_34.so
lrwxrwxrwx 1 root root 28 2007-07-08 11:47 /usr/lib/libboost_regex-st.so -> libboost_regex-gcc41-1_34.so
Unlike every other library on my system, the Boost libraries have the
compiler (gcc41) and threading model (mt|st) and so on embedded *in
the library name*. This makes it impossible to discover in an
automatic fashion. Since this is free software anyone can download
and build, I don't know what the compiler/toolchain will be, let alone
what abbreviation Boost has chosen for it. I expect that Autoconf
will set up such things appropriately.
The only means I have are the libboost_program_options-mt.so,
libboost_program_options-st.so (and so on for all the libraries)
symbolic links which the Debian maintainer has helpfully provided.
However, these are not portable, and are so not a good solution. They
are, however, the only available solution at the moment.
To further show the problem I am having, this is part of my
configure.ac Autoconf template:
---configure.ac----
AC_CHECK_HEADERS([tr1/memory])
AC_CHECK_HEADERS([boost/shared_ptr.hpp],, [
if test $ac_cv_header_tr1_memory = yes; then
:
else
AC_MSG_ERROR([Boost.shared_ptr (Boost C++ Libraries) is not installed, but is required by schroot])
fi])
AC_CHECK_HEADERS([tr1/tuple])
AC_CHECK_HEADERS([boost/tuple/tuple.hpp],, [
if test $ac_cv_header_tr1_memory = yes; then
:
else
AC_MSG_ERROR([Boost.Tuple (Boost C++ Libraries) is not installed, but is required by schroot])
fi])
AC_CHECK_HEADERS([boost/format.hpp],, [AC_MSG_ERROR([Boost.Format (Boost C++ Libraries) is not installed, but is required by schroot])])
AC_CHECK_HEADERS([boost/program_options.hpp],, [AC_MSG_ERROR([Boost.Program_options (Boost C++ Libraries) is not installed, but is required by schroot])])
AC_CHECK_HEADERS([boost/type_traits.hpp],, [AC_MSG_ERROR([Boost.TypeTraits (Boost C++ Libraries) is not installed, but is required by schroot])])
AC_MSG_CHECKING([for boost::program_options::variables_map in -lboost_program_options-st])
saved_ldflags="${LDFLAGS}"
LDFLAGS="${LDFLAGS} -lboost_program_options-st"
AC_LINK_IFELSE([AC_LANG_PROGRAM([#include ],
[boost::program_options::variables_map::variables_map dummy()])],
[AC_MSG_RESULT([yes])
BOOST_LIBS="${BOOST_LIBS} -lboost_program_options-st"],
[AC_MSG_RESULT([no])
AC_MSG_FAILURE([libboost_program_options (Boost C++ Libraries) is not installed, but is required by schroot])])
LDFLAGS="${saved_ldflags}"
AC_MSG_CHECKING([for boost::program_options::options_description::options() in -lboost_program_options-st])
saved_ldflags="${LDFLAGS}"
LDFLAGS="${LDFLAGS} -lboost_program_options-st"
AC_LINK_IFELSE([AC_LANG_PROGRAM([#include ],
[boost::program_options::options_description testgrp("test group");
bool notused = testgrp.options().empty();
])],
[AC_MSG_RESULT([yes])
BOOST_PROGRAM_OPTIONS_DESCRIPTION_METHODS="current"],
[AC_MSG_RESULT([no])
BOOST_PROGRAM_OPTIONS_DESCRIPTION_METHODS="old"])
LDFLAGS="${saved_ldflags}"
AH_TEMPLATE(BOOST_PROGRAM_OPTIONS_DESCRIPTION_OLD, [Set if boost::program_options::options_description::options() is not available])
if test "$BOOST_PROGRAM_OPTIONS_DESCRIPTION_METHODS" = "old"; then
AC_DEFINE(BOOST_PROGRAM_OPTIONS_DESCRIPTION_OLD, 1)
fi
AC_MSG_CHECKING([for boost::regex in -lboost_regex-st])
saved_ldflags="${LDFLAGS}"
LDFLAGS="${LDFLAGS} -lboost_regex-st"
AC_LINK_IFELSE([AC_LANG_PROGRAM([#include ],
[boost::regex("^foo[bar]$")])],
[AC_MSG_RESULT([yes])
BOOST_LIBS="${BOOST_LIBS} -lboost_regex-st"],
[AC_MSG_RESULT([no])
AC_MSG_FAILURE([libboost_regex (Boost C++ Libraries) is not installed, but is required by schroot])])
LDFLAGS="${saved_ldflags}"
AC_SUBST([BOOST_LIBS])
---configure.ac----
As you can see, that's quite a bit of complexity. It also includes
code to work around a backwards compatibility issue in
Boost.Program_options. However, it needs to know the library name in
order to link the test code, and I'm still needing to use a
non-standard name in order to do that.
It would be great if Boost would provide a mechanism to allow such
discovery. Such a mechanism already exists, and is called
"pkg-config". By installing a small file in LIBDIR/pkgconfig for each
Boost library, the pkg-config tool or PKG_CHECK_MODULES Autoconf macro
may be used to query this information. As an example:
---- boost-regex-mt.pc ----
prefix=/usr
exec_prefix=${prefix}
libdir=${exec_prefix}/lib
includedir=${prefix}/include
Name: boost-regex-mt
Description: Boost C++ Regular Expression Library (multi-threaded)
Version: 1.34.0
Libs: -L${libdir} -lboost_regex-gcc41-mt-1_34
Libs.private: -licui18n -licuuc -lrt -lm
Cflags: -I${includedir} -pthread
---- boost-regex-mt.pc ----
You can generate this from a template:
---- boost-regex-mt.pc.in ----
prefix=PREFIX
exec_prefix=EPREFIX
libdir=LIBDIR
includedir=INCLUDEDIR
Name: boost-regex-mt
Description: Boost Regular Expression Library (multi-threaded)
Version: VERSION
Libs: -L${libdir} LIBRARY_NAME
Libs.private: LIBRARY_DEPENDENCIES [for static linking]
Cflags: -I${includedir} THREAD_OPTIONS_FOR_COMPILER
---- boost-regex-mt.pc.in ----
where the capitalised names are where you would substitute in the
system- and compiler-specific options. It looks like bjam could
probably make this a single rule all libraries could make use of.
For such a setup, all that configure script above could be mostly
reduced to
PKG_CHECK_MODULES([boost-regex-st])
PKG_CHECK_MODULES([boost-program-options-st])
I don't know how bjam works, but I do this with Autoconf as a file
generated by config.status, but it could also be generated by make
with a simple sed command. I guess you could do the bjam equivalent,
whatever that might be. I have had a look at the sources to try to
implement this, but I am afraid I lack the bjam expertise to do it.
You may find much more detailed discussion of these issues at
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=424038
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=424666
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=425264
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=428419
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=350539
Some of these are due to Debian-specific issues (a change to the
symlink name), but the root cause is the inability to identify the
Boost library names in an automated fashion.
Regards,
Roger
--
.''`. Roger Leigh
: :' : Debian GNU/Linux http://people.debian.org/~rleigh/
`. `' Printing on GNU/Linux? http://gutenprint.sourceforge.net/
`- GPG Public Key: 0x25BFB848 Please GPG sign your mail.
