Re: [boost] Finding the correct library to link (feature request for pkg-config support)

From: Vladimir Prus (ghost_at_[hidden])
Date: 2007-07-14 09:23:08

Roger Leigh wrote:

> 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

This indicates a bug with Debian packages. All Linux packagers are supposed
to building Boost with the --layout=system option. Passing such option will
produce names like

        libboost_program_options-mt.so
 
> 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.

Had they used --layout=system, there would be no need to provide the
symlinks ;-)

> 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.hpp>],
>                                [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}"
...

> As you can see, that's quite a bit of complexity.  

Note that the complexity you have shown (saving ldflags and
the like) has nothing to do with how boost libraries are named. 
Instead, it seems that either:
        1. autoconf is not capable of easily compiling and linking
        a random C++ code to see if it works.
        2. You don't know the right spell to make it do so.
        (Actually, I recall having used exactly same voodoo in
        past, but I don't use autoconf regularly).

> 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 ----

So,
1. The names of libraries Boost produces on your system are rather non-standard.
2. You propose to add a set of files with canonical names, that 
give names of Boost libraries?

I think that we should do the following instead:

1. Generally change build process to no longer produce
zillion of variants, at least on Linux. 

2. Make sure "system layout" produces exactly that. In particular,
the "-mt" suffix should disappear. As result, names like 
libboost_program_options.so will be used.

3. Make "system" layout the default, at least on Linux. Alternatively,
write a special docs for packages that says: "for packaging Boost, use
--layout=system"

How does that sound?

- Volodya