boost 1.46.0

Braden McDaniel braden at
Fri Feb 4 21:53:28 UTC 2011

On 2/4/11 4:11 PM, Bastien Nocera wrote:
> On Fri, 2011-02-04 at 15:41 -0500, Braden McDaniel wrote:
>> On 2/4/11 3:10 PM, Bastien Nocera wrote:


>>> Could we please either have boost.m4 packaged in Fedora, or at least
>>> changes for running with the latest boost in Fedora integrated upstream?
>>> Because of boost changes between December and yesterday, I wasn't able
>>> to recompile gnote:
>>> The build failures are here:
>>> It's critical if we want gnote in F15's GNOME desktop.
>> Isn't boost.m4 just some third-party macro?
>> Perhaps upstream could be encouraged not to use it?


> I'm pretty sure the gnote developers would take any patches to remove
> that code, as long as it did detection as you mentioned above. If boost
> provided a pkg-config file, or their own macros, I'm pretty sure that
> gnote wouldn't be using it.
> I don't know enough about boost to make those changes myself, and wading
> through 2 tarballs of 40 megs each to figure out the library layout of
> boost is a bit beyond me.

I am pretty sure that wading is unnecessary.

All I do in my own Boost-dependent project is this:


AS_IF([test -z "${BOOST_LIB_SUFFIX+x}"], [BOOST_LIB_SUFFIX=-mt])
AC_ARG_VAR([BOOST_LIB_SUFFIX], [Boost library name suffix [default=-mt]])

AC_CACHE_CHECK([for boost_thread$BOOST_LIB_SUFFIX library],
LIBS="-lboost_thread$BOOST_LIB_SUFFIX $LIBS"
AC_LINK_IFELSE([AC_LANG_PROGRAM([[#include <boost/thread.hpp>]],
                                 [[boost::thread t]])],
AS_IF([test X$ov_cv_boost_thread = Xno],
       [AC_MSG_FAILURE([libboost_thread$BOOST_LIB_SUFFIX not found])])


Then, references to Boost libraries in need to look like 

And you're done.

As you can see, I don't do any detection of the Boost library suffix; 
and I don't have a very high opinion of attempts to do so.  Indeed, I'm 
generally of the mind that attempts simply to detect features that are 
implemented consistently (when present at all) are misguided.  When such 
diagnostics are trivial or incidental, they're fine.  But as soon as 
they're the least bit nontrivial, you've got an unnecessary test that 
can break--and that's a very silly reason for your package to stop building.


More information about the devel mailing list