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