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

From: Neal Becker (ndbecker2_at_[hidden])
Date: 2007-07-23 11:37:39

Vladimir Prus wrote:

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

I think typically linux distros want the version, but not the 'gcc41' part. 
We really do need to allow multiple versions, as is common practice with
other shared libs on linux systems.  Since multiple compilers are uncommon,
distros normally ignore that.  These statements are true on redhat/fedora,
at least.  Since boost doesn't provide an option for this, on redhat the
jamfiles were hacked to do it.