Opened 6 years ago

Closed 3 months ago

#7085 closed Bugs (fixed)

Boost pool library it not header only as claimed in documentation

Reported by: Roger Pawlowski <rppawlo@…> Owned by: Chris Newbold
Milestone: To Be Determined Component: pool
Version: Boost 1.50.0 Severity: Problem
Keywords: pool header only Cc: vz-xmlwrapp@…

Description

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.

Change History (11)

comment:1 Changed 6 years ago by 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.

comment:2 Changed 6 years ago by anonymous

tnx

comment:3 Changed 6 years ago by dpantele

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

comment:4 Changed 5 years ago by anonymous

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

comment:5 Changed 5 years ago by 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.

comment:6 Changed 4 years ago by vz-xmlwrapp@…

Cc: vz-xmlwrapp@… added

comment:7 Changed 4 years ago by 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?

comment:7 Changed 4 years ago by 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?

comment:8 in reply to:  7 Changed 4 years ago by 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?

comment:9 Changed 18 months ago by 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?

comment:10 Changed 3 months ago by Michael Caisse

Resolution: fixed
Status: newclosed

Resolved with 9def9a536f5bc69922065a875d27f8918afa76f5

Note: See TracTickets for help on using tickets.