Yeah, that is what was happening. The minimal implementation needed for libsa was missing.
On Sat, Oct 31, 2020, at 3:33 PM, Brandon Bergren wrote: > Maybe this is it?: > > Index: sys/contrib/openzfs/include/os/freebsd/spl/sys/atomic.h > =================================================================== > --- sys/contrib/openzfs/include/os/freebsd/spl/sys/atomic.h (revision > 367230) > +++ sys/contrib/openzfs/include/os/freebsd/spl/sys/atomic.h (working copy) > @@ -188,6 +188,8 @@ > */ > #undef atomic_add_64 > #define atomic_add_64(ptr, val) *(ptr) += val > +#undef atomic_sub_64 > +#define atomic_sub_64(ptr, val) *(ptr) -= val > #endif /* !_STANDALONE */ > > #endif /* !_OPENSOLARIS_SYS_ATOMIC_H_ */ > > > Note that there is also another build failure in the tree at the moment. > > On Sat, Oct 31, 2020, at 3:25 PM, Brandon Bergren wrote: > > Actually, looking at it again, it looks like the spl header is doing it > > wrong and not providing a fallback for atomic_sub_64, it's just > > defining it to atomic_subtract_64 and assuming that exists. > > > > On Sat, Oct 31, 2020, at 3:23 PM, Mateusz Guzik wrote: > > > Yep, jenkins told me. Working on it. > > > > > > On 10/31/20, Brandon Bergren <bdra...@freebsd.org> wrote: > > > > This doesn't compile on platforms such as powerpc without pulling in the > > > > opensolaris atomics header from the spl that does locking emulation of > > > > 64 > > > > bit atomics, as platforms that don't have native 64 bit atomics do not > > > > provide them in the system header. > > > > -- > Brandon Bergren > bdra...@imap.cc > -- Brandon Bergren bdra...@freebsd.org _______________________________________________ svn-src-all@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
