Boost pool library it not header only as claimed in documentation

[Roger Pawlowski <rppawlo@…>]

Hi,

I have been trying to use the bool pool library out of the current release 1.50.0. The documentation page claims the library is header only, but it pulls in the threads library which is not header only. You can reproduce this with the code:

#include <boost/pool/pool_alloc.hpp>

int main () {

return 0;

}

I get the following error on gnu 4.3.5 compilers:

Linking CXX executable Panzer_roger_junk.exe CMakeFiles/Panzer_roger_junk.dir/roger.cpp.o: In function `static_initialization_and_destruction_0': /home/rppawlo/install_boost_1_50_0/include/boost/system/error_code.hpp:214: undefined reference to `boost::system::generic_category()' /home/rppawlo/install_boost_1_50_0/include/boost/system/error_code.hpp:215: undefined reference to `boost::system::generic_category()' /home/rppawlo/install_boost_1_50_0/include/boost/system/error_code.hpp:216: undefined reference to `boost::system::system_category()' collect2: ld returned 1 exit status

The issue is that <boost/pool/pool_alloc.hpp> includes <boost/pool/poolfwd.hpp> which includes <boost/pool/detail/mutex.hpp> which includes <boost/thread/mutex.hpp> which includes <boost/thread/pthread/mutex.hpp> which includes <boost/thread/exceptions.hpp>

The <boost/thread/exceptions.hpp> directly uses the boost system library which is not header only.

[SiliconKiwi]

Yep it pulls in boost::threads as well, even if BOOST_POOL_NO_MT is defined.

Changing the include guard in pool/detail/mutex.hpp around <boost/thread/mutex.hpp> to this:

#if defined (BOOST_HAS_THREADS) && !defined(BOOST_POOL_NO_MT)

fixes the problem, as long as BOOST_POOL_NO_MT is defined.

[anonymous]

tnx

[dpantele]

Probably #if defined(BOOST_HAS_THREADS) && !defined(BOOST_NO_MT) && !defined(BOOST_POOL_NO_MT)

[anonymous]

Issue still present in 1.55. Proposed solution by dpantele looks correct and works as expected.

[nico.schloemer@…]

This bug seems easy to fix, and is a cause for downstream bugs that are hard to debug (e.g., Sandia Trilinos bug 5929). Also, note that boost bug #7335 is a duplicate of this.

Getting the proposed fix in (which does the trick as far as I'm concerned) would be very helpful.

[anonymous]

Unfortunately, the proposed workaround causes a crash when used in a multithreaded application. For this reason, the proposed workaround is useless. Perhaps someone can put back in the light weight version of default_mutex?

[anonymous]

Unfortunately, the proposed workaround causes a crash when used in a multithreaded application. For this reason, the proposed workaround is useless. Perhaps someone can put back in the light weight version of default_mutex?

[Will Wagner <willw@…>]

Replying to anonymous:

Unfortunately, the proposed workaround causes a crash when used in a multithreaded application. For this reason, the proposed workaround is useless. Perhaps someone can put back in the light weight version of default_mutex?

If you use boost/pool_alloc then it is up to you to provide thread synchronisation. Either that or use singlton_pool which deals wit this.

This changes fixes this issue - how can we get someone to actually review this trivial change?

[Laurie]

So I just ran into this bug yesterday, and am a bit disheartened to discover it's been broken for 5 years... Is there any chance of a fix, or is this library no longer supported?

[Michael Caisse]

Resolved with 9def9a536f5bc69922065a875d27f8918afa76f5