Re: [boost] [boost.atomic] linker error with gcc 4.1.2

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
Helge