Boost logo

Boost :

Subject: Re: [boost] [boost.atomic] linker error with gcc 4.1.2
From: Helge Bahmann (hcb_at_[hidden])
Date: 2010-03-05 02:43:12

On Fri, 5 Mar 2010, Jamie Allsop wrote:

> Helge Bahmann wrote:
>> Hi Jamie,
>> On Wed, 3 Mar 2010, Jamie Allsop wrote:
>>> With gcc 4.1.2 (gcc 4.3.x is fine) I am seeing this linker error:
>>> .build/debug/working/SourceOne.o:
>>> In function `void
>>> boost::detail::atomic::platform_atomic_thread_fence<boost::memory_order>(boost::memory_order)':
>>> /thirdparty/boost/boost_1_42/boost/smart_ptr/detail/shared_count.hpp:229:
>>> multiple definition of `void
>>> boost::detail::atomic::platform_atomic_thread_fence<boost::memory_order>(boost::memory_order)'
>>> .build/debug/working/SourceTwo.o:
>>> /thirdparty/boost/boost_1_42/boost/atomic/detail/gcc-x86.hpp:63: first
>>> defined here
>> [...]
>>> Is this a compiler error or should the specialisation be declared as:
>>> template<>
>>> inline void platform_atomic_thread_fence(memory_order order)
>> you are right, it should have been specialized this way. I have however
>> reorganized my development tree such that this is now handled differently
>> (macros instead of via template specialization), so if you are patient
>> until saturday, this will be resolved.
> I patched my copy locally so no rush for me. However I'm curious as to why
> you'd use a macro when a template would do? Or is it that your changes
> preclude using templates or other language facilities? I guess I can have a
> look on Saturday ;)

there has been a request for the abilitiy to detect at compile-time the
lock-freedom of atomic data types, in order to being able to pick
different data structures and code paths. If I have to define macros for
this purpose anyway, there is no good reason anymore to "abuse"
templates as much as I do currently.

Best regards

Boost list run by bdawes at, gregod at, cpdaniel at, john at