On 08.05.2020 21:33, maya%NetBSD.org@localhost wrote:
> On Fri, May 08, 2020 at 04:09:02PM +0200, Kamil Rytarowski wrote:
>> I object to opinions that libatomic is generally broken, if that would
>> be the cause, it wouldn't be available and used on relatively all
>> relevant generic purpose Operating Systems. Personally, I already
>> received last year a feedback from one 3rd party project from Microsoft
>> that they prefer to drop NetBSD support (out of Windows, Linux, MacOS,
>> BSDs) rather than allow non-libatomic usage.
>
> You need to stop being ambiguous about the rationale, it's not helping
> your arguments sound strong. Name the project and link to the
> discussion.
>
NetBSD support #77
https://github.com/microsoft/snmalloc/pull/77#issuecomment-517375185
davidchisnall commented on 1 Aug 2019
If the NetBSD developers disagree with the libatomic idea, what is their
alternative? Or do they just decide not to support C11 / C++11? I'll
happily review a patch to properly support NetBSD (which means linking
whatever the NetBSD equivalent of libatomic is), but otherwise it's
probably better to remove the NetBSD PAL rather than leave something
that only works in non-default configurations.
davidchisnall commented on 1 Aug 2019
We only need 128-bit atomics, but it sounds as if the compiler that
NetBSD ships by default does not emit 128-bit atomics even with the
-mcx16 flag. There are three reasonable approaches here:
Ship libatomics.
Ship another library that provides these symbols (e.g. put them in
libc).
Ship a compiler that implements _Atomic in some other way and does
not depend on the __atomic_compare_exchange_{16,n} symbols.
Shipping a compiler that emits calls to support library functions and
then not shipping the support library is the worst possible solution.
The required CMake changes on our side would be quite complex unless we
just say reject trying to compile with gcc on NetBSD entirely.
davidchisnall commented on 2 Aug 2019
We only add libatomic when compiling with gcc, so I think the current
logic is correct. If NetBSD ever ships a version of GCC that actually
works, then we can revisit this, otherwise NetBSD users will get an
error when they try to link with GCC but have everything work when they
compile with clang.
Attachment:
signature.asc
Description: OpenPGP digital signature