[atomic] [release] possible linking problem with atomic (was: [1.53.0] Beta release candidates available)
Fwd'ed from the users list... On 1/10/2013 9:37 AM, Olivier Tristan wrote:
Hi,
Don't know if It's suppose to be normal but it looks that the newly added boost atomic requires linking against a static lib by default. This seems wrong as this an header only package.
Please note that I'm using a fresh 1.53 beta 1 with no define like BOOST_ATOMIC_DYN_LINK or BOOST_ALL_DYN_LINK
BOOST_DYN_LINK is greyed out when I open the header in the editor so it doesn't look like to be defined.
(Visual c++ 2005 SP1)
Am I missing something here ?
Thanks !
On Thu, Jan 10, 2013 at 9:46 PM, Eric Niebler <eric@boostpro.com> wrote:
Fwd'ed from the users list...
On 1/10/2013 9:37 AM, Olivier Tristan wrote:
Hi,
Don't know if It's suppose to be normal but it looks that the newly added boost atomic requires linking against a static lib by default. This seems wrong as this an header only package.
Please note that I'm using a fresh 1.53 beta 1 with no define like BOOST_ATOMIC_DYN_LINK or BOOST_ALL_DYN_LINK
BOOST_DYN_LINK is greyed out when I open the header in the editor so it doesn't look like to be defined.
(Visual c++ 2005 SP1)
Am I missing something here ?
Thanks !
As I understand, static libs are the default on Windows. So unless specified otherwise, Boost.Atomic follows other libs in this regard. Note that it is ok to link statically with Boost.Atomic if only one module of the application uses it.
On Thu, Jan 10, 2013 at 7:17 PM, Andrey Semashev <andrey.semashev@gmail.com> wrote:
On Thu, Jan 10, 2013 at 9:46 PM, Eric Niebler <eric@boostpro.com> wrote:
Fwd'ed from the users list...
On 1/10/2013 9:37 AM, Olivier Tristan wrote:
Hi,
Don't know if It's suppose to be normal but it looks that the newly added boost atomic requires linking against a static lib by default. This seems wrong as this an header only package.
Please note that I'm using a fresh 1.53 beta 1 with no define like BOOST_ATOMIC_DYN_LINK or BOOST_ALL_DYN_LINK
BOOST_DYN_LINK is greyed out when I open the header in the editor so it doesn't look like to be defined.
(Visual c++ 2005 SP1)
Am I missing something here ?
Thanks !
As I understand, static libs are the default on Windows. So unless specified otherwise, Boost.Atomic follows other libs in this regard.
Note that it is ok to link statically with Boost.Atomic if only one module of the application uses it.
The point is the user appears to think it's a header-only lib. -- Olaf
On Thu, Jan 10, 2013 at 10:54 PM, Olaf van der Spek <ml@vdspek.org> wrote:
On Thu, Jan 10, 2013 at 7:17 PM, Andrey Semashev <andrey.semashev@gmail.com> wrote:
On Thu, Jan 10, 2013 at 9:46 PM, Eric Niebler <eric@boostpro.com> wrote:
Fwd'ed from the users list...
On 1/10/2013 9:37 AM, Olivier Tristan wrote:
Hi,
Don't know if It's suppose to be normal but it looks that the newly added boost atomic requires linking against a static lib by default. This seems wrong as this an header only package.
Please note that I'm using a fresh 1.53 beta 1 with no define like BOOST_ATOMIC_DYN_LINK or BOOST_ALL_DYN_LINK
BOOST_DYN_LINK is greyed out when I open the header in the editor so it doesn't look like to be defined.
(Visual c++ 2005 SP1)
Am I missing something here ?
Thanks !
As I understand, static libs are the default on Windows. So unless specified otherwise, Boost.Atomic follows other libs in this regard.
Note that it is ok to link statically with Boost.Atomic if only one module of the application uses it.
The point is the user appears to think it's a header-only lib.
Oh, I missed that. Well, it's not a header-only library.
On 10.1.2013. 20:02, Andrey Semashev wrote:
Well, it's not a header-only library.
That's a bit 'sad' given that 'most' platforms/compilers support builtin atomic operations/instructions... Is there anyway (e.g. define a configuration macro) to make the library work as header-only on those platforms (e.g. x86 and ARM)? Can the library be changed in the future so that it includes "spin-lock pools&co" and thus requires linking only when building for unsupported platforms/platforms without atomic operations? -- "What Huxley teaches is that in the age of advanced technology, spiritual devastation is more likely to come from an enemy with a smiling face than from one whose countenance exudes suspicion and hate." Neil Postman
On Friday 11 January 2013 17:35:54 Domagoj Saric wrote:
On 10.1.2013. 20:02, Andrey Semashev wrote:
Well, it's not a header-only library.
That's a bit 'sad' given that 'most' platforms/compilers support builtin atomic operations/instructions... Is there anyway (e.g. define a configuration macro) to make the library work as header-only on those platforms (e.g. x86 and ARM)?
No, currently there isn't one. Note that the pool of spinlocks can be used even on platforms with hardware support for atomics (e.g. when the atomic<T> is used for a too large T).
Can the library be changed in the future so that it includes "spin-lock pools&co" and thus requires linking only when building for unsupported platforms/platforms without atomic operations?
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.
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.
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.
that's exactly the reason, why i suggested to build a shared library only. multi-module applications should *not* link to a static lib if they share atomic objects. being able to use a (lock-free) subset as header-only library would be quite convenient, though ... cheers, tim
Tim Blechmann wrote:
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.
that's exactly the reason, why i suggested to build a shared library only. multi-module applications should *not* link to a static lib if they share atomic objects.
Isn't this only true on Windows? (Unless the spinlock pool has visibility=hidden, but it shouldn't).
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.
that's exactly the reason, why i suggested to build a shared library only. multi-module applications should *not* link to a static lib if they share atomic objects.
Isn't this only true on Windows? (Unless the spinlock pool has visibility=hidden, but it shouldn't).
i'm definitely not an expert on dynamic linking, but when loading a library with dlopen (and RTLD_LOCAL), symbols in this library won't be used to resolve references in other libraries. so if two shared libraries both statically link to boost.atomic, i'd expect to have one spinlock pool per library. tim
On January 11, 2013 9:15:39 PM "Peter Dimov" <lists@pdimov.com> 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.
On 11.1.2013. 17:47, Andrey Semashev wrote:
On Friday 11 January 2013 17:35:54 Domagoj Saric wrote:
On 10.1.2013. 20:02, Andrey Semashev wrote:
Well, it's not a header-only library.
That's a bit 'sad' given that 'most' platforms/compilers support builtin atomic operations/instructions... Is there anyway (e.g. define a configuration macro) to make the library work as header-only on those platforms (e.g. x86 and ARM)?
No, currently there isn't one.
You mean that even if I only instantiate Boost.Atomic templates for hardware/OS supported types while only including the header(s) (w/o explicit linking) I will get linker errors? If so, that's rather unfortunate (as it renders Boost.Atomic useless for me and it also 'smells' of some unnecessary coupling)... ps. apologies for the delay... -- "What Huxley teaches is that in the age of advanced technology, spiritual devastation is more likely to come from an enemy with a smiling face than from one whose countenance exudes suspicion and hate." Neil Postman
That's a bit 'sad' given that 'most' platforms/compilers support builtin atomic operations/instructions... Is there anyway (e.g. define a configuration macro) to make the library work as header-only on those platforms (e.g. x86 and ARM)?
No, currently there isn't one. You mean that even if I only instantiate Boost.Atomic templates for hardware/OS supported types while only including the header(s) (w/o explicit linking) I will get linker errors?
i'm not really familiar with the autolinking stuff for win32, but checking the sources, it seems you can disable it with by defining BOOST_ATOMIC_NO_LIB ...
On 1/10/2013 1:17 PM, Andrey Semashev wrote:
On Thu, Jan 10, 2013 at 9:46 PM, Eric Niebler <eric@boostpro.com> wrote:
Fwd'ed from the users list...
On 1/10/2013 9:37 AM, Olivier Tristan wrote:
Hi,
Don't know if It's suppose to be normal but it looks that the newly added boost atomic requires linking against a static lib by default. This seems wrong as this an header only package.
Please note that I'm using a fresh 1.53 beta 1 with no define like BOOST_ATOMIC_DYN_LINK or BOOST_ALL_DYN_LINK
BOOST_DYN_LINK is greyed out when I open the header in the editor so it doesn't look like to be defined.
(Visual c++ 2005 SP1)
Am I missing something here ?
Thanks !
As I understand, static libs are the default on Windows. So unless specified otherwise, Boost.Atomic follows other libs in this regard.
I highly doubt that "static libs are the default on Windows", however you deem to determine such a thing, from my own practical experience as a developer and end-user. Nearly all applications for Windows on which I have worked as well all major applications which I have used are distributed as applications with DLLs rather than as monolithic applications built by linking in static libraries. Needless to say the MS .Net framework as well as the new Windows 8 run-time framework is built around DLLs ( or assemblies ) rather than static libraries. In Visual Studio, easily the most popular Windows IDE, the VC++ modules all link by default to the DLL version of libraries ( RTL, MFC, ATL etc. etc. ). Of course you can change this but the default is DLLs, not static libs.
[Edward Diener]
In Visual Studio, easily the most popular Windows IDE, the VC++ modules all link by default to the DLL version of libraries ( RTL, MFC, ATL etc. etc. ). Of course you can change this but the default is DLLs, not static libs.
Amusingly, static linking is the default in a relatively trivial way - if you invoke the compiler from the command line and don't specifically select one of the four flavors, you get static release: C:\Temp>type meow.cpp #include <stdio.h> int main() { #ifdef _DLL printf("Dynamic "); #else printf("Static "); #endif #ifdef _DEBUG puts("Debug"); #else puts("Release"); #endif } C:\Temp>cl /EHsc /nologo /W4 /MT meow.cpp && meow meow.cpp Static Release C:\Temp>cl /EHsc /nologo /W4 /MTd meow.cpp && meow meow.cpp Static Debug C:\Temp>cl /EHsc /nologo /W4 /MD meow.cpp && meow meow.cpp Dynamic Release C:\Temp>cl /EHsc /nologo /W4 /MDd meow.cpp && meow meow.cpp Dynamic Debug C:\Temp>cl /EHsc /nologo /W4 meow.cpp && meow meow.cpp Static Release This is unrelated to the question of whether Boost libs should link statically or dynamically by default (as I recall, Boost.Regex defaults to static, but I haven't checked recently). Stephan T. Lavavej Visual C++ Libraries Developer
On Thursday 10 January 2013 22:08:28 Edward Diener wrote:
On 1/10/2013 1:17 PM, Andrey Semashev wrote:
As I understand, static libs are the default on Windows. So unless specified otherwise, Boost.Atomic follows other libs in this regard.
I highly doubt that "static libs are the default on Windows", however you deem to determine such a thing, from my own practical experience as a developer and end-user.
I was referring to Boost.Build defaults on Windows. I'm not judging whether the choice is justified, I'm just pointing out that Boost.Atomic follows the default build options on that platform.
Nearly all applications for Windows on which I have worked as well all major applications which I have used are distributed as applications with DLLs rather than as monolithic applications built by linking in static libraries.
I'd say there are applications built with both approaches and we cannot base our expectations on a few select ones.
Needless to say the MS .Net framework as well as the new Windows 8 run-time framework is built around DLLs ( or assemblies ) rather than static libraries.
In Visual Studio, easily the most popular Windows IDE, the VC++ modules all link by default to the DLL version of libraries ( RTL, MFC, ATL etc. etc. ). Of course you can change this but the default is DLLs, not static libs.
Yes, you're right, although the libraries you list are typically available in Windows distribution and applications need not to worry distributing them. Boost is different in this regard. I'm not advocating for the static linking approach. Either way has its pros and cons. FWIW, I would probably prefer to build everything by default and let the user decide what he wants.
On Fri, Jan 11, 2013 at 9:15 AM, Andrey Semashev <andrey.semashev@gmail.com> wrote:
In Visual Studio, easily the most popular Windows IDE, the VC++ modules all link by default to the DLL version of libraries ( RTL, MFC, ATL etc. etc. ). Of course you can change this but the default is DLLs, not static libs.
Yes, you're right, although the libraries you list are typically available in Windows distribution and applications need not to worry distributing them. Boost is different in this regard.
That's not true, unfortunately. You'll have to take care of redistributing the relevant installer yourself or link statically. -- Olaf
participants (8)
-
Andrey Semashev -
Domagoj Saric -
Edward Diener -
Eric Niebler -
Olaf van der Spek -
Peter Dimov -
Stephan T. Lavavej -
Tim Blechmann