On Feb 15 2018, Palmer Dabbelt <pal...@dabbelt.com> wrote:
> On Mon, 12 Feb 2018 15:18:39 PST (-0800), Jim Wilson wrote:
>> On 02/12/2018 03:23 AM, Andreas Schwab wrote:
>>> On Feb 06 2017, Palmer Dabbelt <pal...@dabbelt.com> wrote:
>>>
>>>> +/* Because RISC-V only has word-sized atomics, it requries libatomic where
>>>> + others do not. So link libatomic by default, as needed. */
>>>> +#undef LIB_SPEC
>>>> +#ifdef LD_AS_NEEDED_OPTION
>>>> +#define LIB_SPEC GNU_USER_TARGET_LIB_SPEC \
>>>> + " %{pthread:" LD_AS_NEEDED_OPTION " -latomic " LD_NO_AS_NEEDED_OPTION
>>>> "}"
>>>> +#else
>>>> +#define LIB_SPEC GNU_USER_TARGET_LIB_SPEC " -latomic "
>>>> +#endif
>>>
>>> Why is -latomic added only with -pthread if --as-needed is supported,
>>> but unconditionally if not? Wouldn't it make sense to add it
>>> unconditionally in both cases?
>>
>> I don't know the history here, but I do know that the most common atomic
>> related bug report we get is for people using pthread, so we were
>> probably thinking about that when this was written.
>
> IIRC that's why it's done this way.
This is a problem for gcc itself, libstdc++-v3 is failing its atomic
checks due to this (PR84568):
checking for atomic builtins for bool... no
checking for atomic builtins for short... no
checking for atomic builtins for int... yes
checking for atomic builtins for long long... yes
configure: WARNING: No native atomic operations are provided for this platform.
configure: WARNING: They will be faked using a mutex.
configure: WARNING: Performance of certain classes will degrade as a result.
But it wouldn't have found -latomic anyway. There needs to be a generic
solution for that.
Another affected package is mariadb.
Andreas.
--
Andreas Schwab, SUSE Labs, sch...@suse.de
GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE 1748 E4D4 88E3 0EEA B9D7
"And now for something completely different."
