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

From: Vladimir Prus (ghost_at_[hidden])
Date: 2007-07-30 02:09:43

Roger Leigh wrote:

>>> 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.
.....
> Autoconf compiles and links a test program.  For C, it can test any
> function by simply prototyping and then calling "char func();".  But
> for a C++ library, we might need to attempt to construct an object,
> which might require constructor arguments.  It's not possible to do
> this in a manner which is both robust and generic, hence the need to
> write a small code snippet to instantiate an object (and possibly do
> something with it).
> 
> It would be possible to further generalise the above with a custom m4
> Autoconf macro for doing just this, but I have not felt the need to do
> that just yet.

I'm not going to discuss what would be the most terse autoconf solution,
the point remains that most of complexity of your snippet you've posted
is unrelated to how boost libraries are named. 

>> So,
>> 1. The names of libraries Boost produces on your system are rather
>> non-standard.
> 
> But, these are the configured defaults.

What are "configured defaults"? 

>> 2. You propose to add a set of files with canonical names, that
>> give names of Boost libraries?
> 
> Yes.  However, the proposal serves several purposes which I thought I
> had (perhaps badly) expressed in my original mail, but I will attempt
> to elaborate further here.
> 
>> 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.
> 
> This is, at least on GNU/Linux, and probably also other UNIX variants
> such as BSD and Solaris, a good idea.  However, it does not address a
> fundamental issue:
> 
> If I write a program making use of the Boost libraries, and write a
> Makefile to build it (forget Autoconf for the moment), this is still
> only going to build on a system configured with layout=system.  What
> if I give that code to a Windows user?  I expect it to build, but I
> still have the library naming issue to contend with.

On Windows, your user will have to consider for himself what specific
variant he wants. Using any particular hard-coded variant is likely to 
be wrong.

Let's put it this way. pkgconfig is capable of expanding 'boost' into
a bunch of -l, -L and -I compiler options. pkgconfig is not capable of
dealing with variants. Therefore, pkgconfig can be only used when there's
"default variant" that can be linked to. On Linux, we can decide what
such variant is. I'm not sure such default variant can be easily established
on Windows, so pkgconfig is of limited use there.

Heh, is pkgconfig a standard thing on Windows boxes? I doubt that.

> This is the real issue I would like to address.
> 
>> 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.
> 
> This would, I presume, make multi-threaded libraries the default?  One
> issue discussed in the original bug reports I referenced was concerns
> that this would have a performance impact for single-threaded
> programs, or worse, actually cause problems in certain circumstances
> if e.g. the wrong compiler/linker options were used.  

Given that pkgconfig does not handle variants, boost.pc would have to
specify some specific variant. Always using MT can, in theory, cause
problems. Always using ST is very likely to lead to problems.

> Could anyone 
> clarify that?  e.g. what if -pthread isn't used while linking (for
> GCC)?

There's no universal answer. Some libraries might be broken if MT
library is used in ST application.

>> 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?
> 
> I agree with your proposal, but would like to add a few further points
> which I think need consideration:
> 
> 1) As mentioned above, I want to write code that will compile on
>    platforms other than the one I use myself (GNU/Linux).  While your
>    proposal will fix building on (new) GNU/Linux installations, it
>    will not make the code compile on other operating systems such as
>    Windows or Solaris which are not using layout=system.

Would you please specify what variant should be used on Windows, and why?

>    pkg-config would provide a discovery mechanism which would work on
>    all platforms and in all cases, however Boost was built.
> 
>    pkg-config is non-intrusive, so users who have no interest in
>    pkg-config are not forced to use it, but it does mean that it can
>    be used in Makefiles directly and Autoconf configure scripts via
>    PKG_CHECK_MODULES.  This would be a big boon for those users.
> 
> 2) pkg-config also provides other extra information in addition to the
>    library name for linking:
> 
>    a) The CFLAGS needed to build.  This might be as simple as a
>       -Iincludedir, but could also include -Ddef and threading options,
>       such as -pthread if using multithreaded libraries.
> 
>    b) LDFLAGS including the library directory -Ldir option, needed to
>       find the correct instance of the library and the -llibrary
>       option.
> 
>    c) Libs.private is a list of dependent libraries needed to link.
>       When linking dynamically, at least on ELF systems, dependent
>       libraries are seen as NEEDED entries in the dynamic section of
>       the symbol table.  But, static libraries carry no dependency
>       information; you have to know, and this provides a mechanism to
>       link statically by allowing discovery of the depdendencies.
> 
>       Maybe I need to link to libicu, maybe I don't.  This can be
>       tailored to the specific build of Boost, so there's no
>       ambiguity.  i.e. the pkg-config file is generated with plaform-,
>       compiler- and build-specific information embedded in it as
>       needed.
> 
>     d) Requires and Conflicts can specify versioned dependencies for
>     other libraries also using pkg-config.  Currently, I don't think
>     you would need this, but libraries based on Boost libraries can
>     then Require boost pkg-config modules.

Those (a)-(c) points above are the most clear explanations of pkgconfig
benefits I've heard on this list, and it appears reasonable to add 
pkgconfig support to Boost.Build. At the same time, I think we *first*
should try to change the build process so that properly named libraries
are created on Linux, so that things work even without pkgconfig. 

- Volodya