Re: [boost] [atomic] [release] possible linking problem with atomic

Subject: Re: [boost] [atomic] [release] possible linking problem with atomic
From: Andrey Semashev (andrey.semashev_at_[hidden])
Date: 2013-01-11 15:20:03

On January 11, 2013 9:15:39 PM "Peter Dimov" <lists_at_[hidden]> wrote:
> Andrey Semashev wrote:
> > That would be a useful improvement and there were discussions of this
> > matter
> > recently (in the context of porting Boost.SmatrPtr to Boost.Atomic). In
> > particular, I proposed to provide a header-only interface for types that
> > can
> > be made atomic on the target platform and a separately included
> > spinlock-based
> > fallback that would require linking.
>
> Is there any point in building a static Boost.Atomic library? I see why it'd
> be necessary to have the spinlock pool in its own DLL on Windows, but a
> static library doesn't seem to be adding anything. DLLs will still have
> separate copies of the spinlock pool. You might as well keep it header-only.

If the pool has weak linkage then the header only solution will work. 
Probably this would be a better solution for single-module applications 
than linking to a static lib. But care should be taken so that this 
header-only mode is not enabled accidentally when not intended. 
Perhaps, wrapping the library into an inline namespace with different 
names based configuration mode will help in this regard. I did this 
trick in Boost.Log.