Re: [boost] Finding the correct library to link (feature request for pkg-config support)
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
Vladimir Prus <ghost@cs.msu.su> writes:
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
Is this documented anywhere? I couldn't find any mention of it.
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 ;-)
This is true. However (as I will detail below), I do not feel that this is a complete solution to the problem.
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).
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. In this specific case, such a test is broken due to not knowing the library name, so this would break if e.g. the configure script was run on Windows. We might also need to know additional information which cannot be automatically found (see below).
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.
But, these are the 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. 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. Could anyone clarify that? e.g. what if -pthread isn't used while linking (for GCC)?
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. 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. (a) and (b) alone are sufficient to allow building if the library has been placed in a location outside the normal search paths for headers and libraries. The name alone is not always sufficient. (c) will allow sane static linking. (d) isn't really an important consideration at this point, but I would probably find a use for it. 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.
Roger Leigh wrote:
Vladimir Prus <ghost@cs.msu.su> writes:
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.
I don't remember saying that Linux packagers should use the --layout=system option. For that matter, I prefer if everyone uses the versioned layout as it produces non-colliding names.
Passing such option will produce names like
libboost_program_options-mt.so
Is this documented anywhere? I couldn't find any mention of it.
Do you mean is --layout documented? ==== --layout=<layout> Determines whether to choose library names and header locations such that multiple versions of Boost or multiple compilers can be used on the same system. versioned (default) - Names of boost binaries include the Boost version number and the name and version of the compiler. Boost headers are installed in a subdirectory of <HDRDIR> whose name contains the Boost version number. system - Binaries names do not include the Boost version number or the name and version number of the compiler. Boost headers are installed directly into <HDRDIR>. This option is intended for system integrators who are building distribution packages. ==== And no, --layout=system will not remove the -mt tag. Also for --layout=versioned, unversioned links are created which remove the Boost version number tag, but not the compiler tag. -- -- Grafik - Don't Assume Anything -- Redshift Software, Inc. - http://redshift-software.com -- rrivera/acm.org - grafik/redshift-software.com -- 102708583/icq - grafikrobot/aim - grafikrobot/yahoo
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
On Mon, Jul 30, 2007 at 10:09:43AM +0400, Vladimir Prus wrote:
Roger Leigh wrote:
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.
let me stress the fact that sources using linux names would not be generally portable to other platforms. such a solution would not be much different from directly using decorated library names, only a little more easy to use. thanks, domenico -----[ Domenico Andreoli, aka cavok --[ http://www.dandreoli.com/gpgkey.asc ---[ 3A0F 2F80 F79C 678A 8936 4FEE 0677 9033 A20E BC50
Domenico Andreoli wrote:
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.
let me stress the fact that sources using linux names would not be generally portable to other platforms.
What platforms you have in mind? If other Unix*, then if library names don't have toolset name in them, there's no problem. - Volodya
On Mon, Jul 30, 2007 at 01:57:31PM +0400, Vladimir Prus wrote:
Domenico Andreoli wrote:
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.
let me stress the fact that sources using linux names would not be generally portable to other platforms.
What platforms you have in mind? If other Unix*, then if library names don't have toolset name in them, there's no problem.
i wrote "generally portable" assuming there are other platforms different from windows and unix which may be supported by boost. don't know, they could be eCos and QNX. one of the goals of Boost is being portable and ported, why make any assumption? sure you did not made too many when you chose to encode the toolset in the decorated names, did you? if you do not care of them (if any), feel free to drop the toolset from the _symlinks_ used to build software, i will not cry :) -----[ Domenico Andreoli, aka cavok --[ http://www.dandreoli.com/gpgkey.asc ---[ 3A0F 2F80 F79C 678A 8936 4FEE 0677 9033 A20E BC50
On 7/30/07, Vladimir Prus <ghost@cs.msu.su> wrote:
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.
How about simply generating the .pc files during the build process? Then the user can install whatever they feel is the right default to their pkgconfig directory. Regards, Michael
Michael Walter wrote:
On 7/30/07, Vladimir Prus <ghost@cs.msu.su> wrote:
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.
How about simply generating the .pc files during the build process? Then the user can install whatever they feel is the right default to their pkgconfig directory.
Let me ask a straight-forward question. Are you using pkgconfig on windows, and if so, is the above what you'd do? My understanding is that right library on windows is highly dependent on the type of project you're building, so there's no one default that can be installed and make the user happy. - Volodya
On 7/30/07, Vladimir Prus <ghost@cs.msu.su> wrote:
Michael Walter wrote:
On 7/30/07, Vladimir Prus <ghost@cs.msu.su> wrote:
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.
How about simply generating the .pc files during the build process? Then the user can install whatever they feel is the right default to their pkgconfig directory.
Let me ask a straight-forward question. Are you using pkgconfig on windows, and if so, is the above what you'd do?
Yes, for projects involving GTK(mm), which comes with and uses pkgconfig. I would then copy the proper boost .pc file to GTK/lib/pkgconfig.
My understanding is that right library on windows is highly dependent on the type of project you're building, so there's no one default that can be installed and make the user happy.
Once you use pkgconfig, you already did settle on a certain configuration (namely the one used by the other libraries proving .pc files). So I'm not sure that it is too much of an issue _in that situation_. What do you think? Regards, Michael
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.
Neal Becker wrote:
I think typically linux distros want the version, but not the 'gcc41' part.
What is the problem with this? It is just a part of the name, isn't it?
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.
Whether this is a good idea is another question... Roland
On Mon, Jul 23, 2007 at 11:37:39AM -0400, Neal Becker wrote:
Vladimir Prus wrote:
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.
IIRC there is a C++ ABI standard definition, which should allow mixing binaries and libraries built with complying compilers. I do not know how much widesprhead is its adoption, IIRC gcc complies starting from 3.2. The point is that it might be too early to drop the toolkint encoding in the library decorated soname even under linux. Suppose a icc user builds its application using a Boost library built with gcc. He could spend days of debugging before discover where is the problem. This issue could well be sorted out at the root, discoverying at build time that there is no suitable Boost library to be used with icc. cheers, domenico -----[ Domenico Andreoli, aka cavok --[ http://www.dandreoli.com/gpgkey.asc ---[ 3A0F 2F80 F79C 678A 8936 4FEE 0677 9033 A20E BC50
Domenico Andreoli wrote:
On Mon, Jul 23, 2007 at 11:37:39AM -0400, Neal Becker wrote:
Vladimir Prus wrote:
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.
IIRC there is a C++ ABI standard definition, which should allow mixing binaries and libraries built with complying compilers. I do not know how much widesprhead is its adoption, IIRC gcc complies starting from 3.2.
The point is that it might be too early to drop the toolkint encoding in the library decorated soname even under linux. Suppose a icc user builds its application using a Boost library built with gcc. He could spend days of debugging before discover where is the problem.
This issue could well be sorted out at the root, discoverying at build time that there is no suitable Boost library to be used with icc.
How? pkgconfig is of no help, since it apparently does not understand "give me libraries to link with when using icc" request. - Volodya
On Mon, Jul 30, 2007 at 09:55:45AM +0400, Vladimir Prus wrote:
Domenico Andreoli wrote:
On Mon, Jul 23, 2007 at 11:37:39AM -0400, Neal Becker wrote:
Vladimir Prus wrote:
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.
IIRC there is a C++ ABI standard definition, which should allow mixing binaries and libraries built with complying compilers. I do not know how much widesprhead is its adoption, IIRC gcc complies starting from 3.2.
The point is that it might be too early to drop the toolkint encoding in the library decorated soname even under linux. Suppose a icc user builds its application using a Boost library built with gcc. He could spend days of debugging before discover where is the problem.
This issue could well be sorted out at the root, discoverying at build time that there is no suitable Boost library to be used with icc.
How? pkgconfig is of no help, since it apparently does not understand "give me libraries to link with when using icc" request.
pkg-config is a de-facto standard but it's still not mandatory :) it would be enough to have a script, a batch or whatever (a binary built using bjam!) which invoked with the right parameters (i.e. toolkit, variant, etc.) is able to build the library name on any system supported by boost. e.g: 1) boost-config --module=date_time --variant=mt --toolkit=gcc --toolkit-version=4.2 --cxxflags everything is specified, the script has nothing to invent. c++ precompiler flags are requested. 2) boost-config --module=date_time --variant=st,debug --toolkit=gcc --ldflags toolkit version is not specified, use default 'gcc'. linker flags are requested to link to single-threaded debug variant. 3) boost-config --module=date_time --variant=mt,static --libs toolkit is not specified, on UNIX cxx may be assumed, on Windows an error is immediately printed. library dependencies are requested (useful when linking static libraris) to link with static multi-threaded variant. IIRC some problems might arise with such a script/program if not done correctly. these problems are correctly handled by pkg-config but could be also managed by boost-config. another option would be to propose a modification of pkg-config. Boost is not the only c++ library here, surely other suffers from the same problems. cheers, domenico -----[ Domenico Andreoli, aka cavok --[ http://www.dandreoli.com/gpgkey.asc ---[ 3A0F 2F80 F79C 678A 8936 4FEE 0677 9033 A20E BC50
Domenico Andreoli wrote:
How? pkgconfig is of no help, since it apparently does not understand "give me libraries to link with when using icc" request.
pkg-config is a de-facto standard but it's still not mandatory :)
it would be enough to have a script, a batch or whatever (a binary built using bjam!) which invoked with the right parameters (i.e. toolkit, variant, etc.) is able to build the library name on any system supported by boost.
e.g:
1) boost-config --module=date_time --variant=mt --toolkit=gcc --toolkit-version=4.2 --cxxflags
everything is specified, the script has nothing to invent. c++ precompiler flags are requested.
I agree that *if* we decide that on Unix, we need all those variants, then such a approach will be useful -- it means users who cares about just some boost to link to will use 'boost-config --cxxflags', while users that want more specific variant won't have to explicitly specify all parts of the name. But I'd say that first we need to decide what variants should actually be built. - Volodya
On Mon, Jul 30, 2007 at 02:04:31PM +0400, Vladimir Prus wrote:
Domenico Andreoli wrote:
How? pkgconfig is of no help, since it apparently does not understand "give me libraries to link with when using icc" request.
pkg-config is a de-facto standard but it's still not mandatory :)
it would be enough to have a script, a batch or whatever (a binary built using bjam!) which invoked with the right parameters (i.e. toolkit, variant, etc.) is able to build the library name on any system supported by boost.
e.g:
1) boost-config --module=date_time --variant=mt --toolkit=gcc --toolkit-version=4.2 --cxxflags
everything is specified, the script has nothing to invent. c++ precompiler flags are requested.
I agree that *if* we decide that on Unix, we need all those variants, then such a approach will be useful -- it means users who cares about just some boost to link to will use 'boost-config --cxxflags', while users that want more specific variant won't have to explicitly specify all parts of the name.
But I'd say that first we need to decide what variants should actually be built.
for what i understood, at least single-thread and multi-thread variants are desired. -----[ Domenico Andreoli, aka cavok --[ http://www.dandreoli.com/gpgkey.asc ---[ 3A0F 2F80 F79C 678A 8936 4FEE 0677 9033 A20E BC50
Neal Becker wrote:
Vladimir Prus wrote:
[snip lots of quoted material]
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.
On Linux system, you don't encode version both in name and the suffix. - Volodya
participants (7)
-
Domenico Andreoli -
Michael Walter -
Neal Becker -
Rene Rivera -
Roger Leigh -
Roland Schwarz -
Vladimir Prus