[atomic] boost.atomic library/win32
hello helge, the shared library of boost.atomic on msvc is currently not really usable, as it does not export the pool_. atm, all boost.lockfree tests of msvc fail for this reason. also according to Zao on irc, it will need some specific treatment to avoid the compilation of a static library. tim [1] http://www.boost.org/development/tests/trunk/developer/lockfree.html
On Thu, Aug 09, 2012 at 01:31:46PM +0200, Tim Blechmann wrote:
hello helge,
the shared library of boost.atomic on msvc is currently not really usable, as it does not export the pool_.
atm, all boost.lockfree tests of msvc fail for this reason. also according to Zao on irc, it will need some specific treatment to avoid the compilation of a static library.
[1] http://www.boost.org/development/tests/trunk/developer/lockfree.html
The rites I had to perform to get Atomic to build in a way that it was usable as a DLL was: In build/Jamfile.v2: Augment the project requirements and lib with <link>shared:<define>BOOST_ATOMIC_DYN_LINK=1 <link>static:<define>BOOST_ATOMIC_STATIC_LINK=1 Create boost/atomic/config.hpp as indicated at [2]. In detail/lockpool.hpp, decorate the lockpool class as: class BOOST_ATOMIC_DECL lockpool and move the member functions that touch pool_ into lockpool.cpp, to avoid them from getting inlined in consumers. As a side note, if Boost.Atomic is supposed to be a compiled library, it should probably implement autolinking as per [3]. I might be off on some things here, but this _should_ make it a good dynamic Boost library. I'm a bit opposed to requiring something to be dynamic however, as that kind of implies that you need a dynamic language runtime. [2] http://www.boost.org/doc/libs/1_50_0/libs/config/doc/html/boost_config/boost... [3] http://www.boost.org/doc/libs/1_50_0/libs/config/doc/html/boost_config/boost... -- Lars Viklund | zao@acc.umu.se
Hi, On Thursday, 9. August 2012 14:26:17 Lars Viklund wrote:
On Thu, Aug 09, 2012 at 01:31:46PM +0200, Tim Blechmann wrote:
atm, all boost.lockfree tests of msvc fail for this reason. also according to Zao on irc, it will need some specific treatment to avoid the compilation of a static library.
A quick workaround is to always link against the static Boost.Atomic (see lockfree_static_atomic.diff attached).
[1] http://www.boost.org/development/tests/trunk/developer/lockfree.html
The rites I had to perform to get Atomic to build in a way that it was usable as a DLL was:
[ snip instructions]
I might be off on some things here, but this _should_ make it a good dynamic Boost library. I'm a bit opposed to requiring something to be dynamic however, as that kind of implies that you need a dynamic language runtime.
Well, it would make a good header only library, because only the static lockpool is compiled into the "library". But this might be required if Atomic is linked against several libraries. The other solution would be to create a static library only, as in atomic_static.diff Any other ideas? Yours, Jürgen -- * Dipl.-Math. Jürgen Hunold ! * voice: ++49 4257 300 ! Fährstraße 1 * fax : ++49 4257 300 ! 31609 Balge/Sebbenhausen * jhunold@gmx.eu ! Germany
Hi, On Thursday, 9. August 2012 14:26:17 Lars Viklund wrote:
On Thu, Aug 09, 2012 at 01:31:46PM +0200, Tim Blechmann wrote:
hello helge,
the shared library of boost.atomic on msvc is currently not really usable, as it does not export the pool_.
atm, all boost.lockfree tests of msvc fail for this reason. also according to Zao on irc, it will need some specific treatment to avoid the compilation of a static library.
[1] http://www.boost.org/development/tests/trunk/developer/lockfree.html
The rites I had to perform to get Atomic to build in a way that it was usable as a DLL was:
[snip necessary steps]
In detail/lockpool.hpp, decorate the lockpool class as: class BOOST_ATOMIC_DECL lockpool and move the member functions that touch pool_ into lockpool.cpp, to avoid them from getting inlined in consumers.
Please find an alternative patch attached. You only have to explicitly export the "pool_" variable. No further changes are required.
As a side note, if Boost.Atomic is supposed to be a compiled library, it should probably implement autolinking as per [3].
Copied and pasted into detail/config.hpp, but not tested. Okay to commit? Any other ideas? Yours, Jürgen -- * Dipl.-Math. Jürgen Hunold ! * voice: ++49 4257 300 ! Fährstraße 1 * fax : ++49 4257 300 ! 31609 Balge/Sebbenhausen * jhunold@gmx.eu ! Germany
On Fri, Aug 10, 2012 at 07:37:39PM +0200, Jürgen Hunold wrote:
On Thursday, 9. August 2012 14:26:17 Lars Viklund wrote:
In detail/lockpool.hpp, decorate the lockpool class as: class BOOST_ATOMIC_DECL lockpool and move the member functions that touch pool_ into lockpool.cpp, to avoid them from getting inlined in consumers.
Please find an alternative patch attached. You only have to explicitly export the "pool_" variable. No further changes are required.
This is sadly false. The static member function which uses pool_ may get inlined in the using TU thanks to being defined implicitly inline in the class definition. At link-time, the user will not be able to resolve the symbol, even though the library exports a symbol by that exact name, thanks to how exported symbols are implicitly indirected one layer. I tried that approach first, and it didn't work. -- Lars Viklund | zao@acc.umu.se
participants (3)
-
Jürgen Hunold -
Lars Viklund -
Tim Blechmann