Build fails on the FreeBSD: undefined reference to `__atomic_store'

[yurivict]

./.libs/libjackserver.so: undefined reference to `__atomic_store'

I narrowed it to this commit: eed8a97

[yurivict]

There is also this generic atomicity library https://github.com/ivmai/libatomic_ops that can be used as a dependency.

[falkTX]

Adding a new dependency just for this seems too much.
Fixing the link error is likely just a matter of adding the correct lib to the linker flags.
Since you're running FreeBSD yourself, can you investigate more?

[yurivict]

I am investigating it.

[yurivict]

It appears that libatomic.a should be added to link line on FreeBSD. However, all versions of libatomic.a that exist belong to gcc, and not to clang.

I asked this question in the FreeBSD bug reporting system. Will wait for their response.

[yurivict]

@jcowgill Why did you add this #if: https://github.com/jackaudio/jack1/blob/master/include/atomicity.h#L23

The top section fails on FreeBSD due to the brokenness of c++ atomics in clang there, but I am curious what is the benefit of using atomic_fetch_add_explicit over __atomic_fetch_add ?

[jcowgill]

There is also this generic atomicity library https://github.com/ivmai/libatomic_ops that can be used as a dependency.

Please DO NOT use that library. It is obsolete and even the author discourages its use.

Why did you add this #if: https://github.com/jackaudio/jack1/blob/master/include/atomicity.h#L23

stdatomic.h is only gaurenteed to exist if that condition is true.

The top section fails on FreeBSD due to the brokenness of c++ atomics in clang there, but I am curious what is the benefit of using atomic_fetch_add_explicit over __atomic_fetch_add ?

atomic_fetch_add_explicit is standard C, whereas __atomic_fetch_add is a GCC extension. When using GCC, they compile to identical code.

---

./.libs/libjackserver.so: undefined reference to __atomic_store'`

I think I can explain this with an example:

#include <stdatomic.h>

struct {
    atomic_int a;
} foo;

struct {
    atomic_int a;

} __attribute__((packed)) bar;

int main(void)
{
    foo.a = 42;
    bar.a = 42;
    return 0;
}

With Clang 5, the bar.a assignment generates an __atomic_store call whereas the foo.a one does not. It seems Clang does this when the structure is packed. GCC however just expands both atomic assignments inline so libatomic is not needed.

[yurivict]

Thanks for your explanation.

Strangely, __atomic_fetch_add is supported by clang despite being a gcc extension.

[jcowgill]

Yeah I think Clang implements quite a lot of GCC extensions.

[yurivict]

This turned out to be the clang bug on FreeBSD. jack1 is the first out of all common C/C++ open source projects that used standard C atomic operations.

Closing, there is a workaround.