https://blogs.gentoo.org/ago/2020/07/04/gentoo-tinderbox/ Issue: sys-cluster/glusterfs-11.1 fails to compile. Discovered on: arm (internal ref: tinderbox_arm) Info about the issue: https://wiki.gentoo.org/wiki/Project:Tinderbox/Common_Issues_Helper#CF0014
Created attachment 887512 [details] build.log build log and emerge --info
Error(s) that match a know pattern in addition to what has been reported in the summary: /usr/lib/gcc/armv7a-unknown-linux-gnueabihf/13/../../../../armv7a-unknown-linux-gnueabihf/bin/ld: ../../libglusterfs/src/.libs/libglusterfs.so: undefined reference to `_uatomic_link_error' collect2: error: ld returned 1 exit status
Temporary fix: CFLAGS="${CFLAGS} -DUATOMIC_NO_LINK_ERROR" CXXFLAGS="${CXXFLAGS} -DUATOMIC_NO_LINK_ERROR" See issue 2979 on gluster github.
David, Are you actively running into this, ie, is a -r1 justified?
Reading through the upstream report it seems the "temporary fix" merely plasters over the real problem, or at least, anything using a 32-bit arch is going to need extra work to simulate atomic 64-bit counters (ie, use a lock). I'm quite frankly OK with that for non-production or "small" setups where performance isn't the key issue. For larger systems we most certainly need to squeeze every bit of performance we can get (on two of our clusters even on NVMe backing stores glusterfs is starting to not quite scale the way we hoped, but the alternatives for our use case is worse). These are 64-bit. As such I'm happy to work with anyone looking to work on a patch, but I'm not going to do so myself. There really is thus two possible paths this can go down on: 1. We generate a patch Gentoo side, and submit upstream in the hopes that it gets included. 2. We de-keyword all 32-bit arches Gentoo side. I'd really prefer to avoid 2 if possible, but given the stance of "We decided to not support 32 bits" and "In this case newer versions won't work on 32 bits platforms even if they compile." (https://github.com/gluster/glusterfs/issues/2979#issuecomment-1036057298) combined with "In this particular case it's necessary to change how things are implemented. It's not just a build configuration. Just changing the value to 32 bits is not enough because it could overflow too fast (it's used to uniquely identify ongoing requests)." (https://github.com/gluster/glusterfs/issues/2979#issuecomment-1040161872) I suspect this may be quite a bit more involved. I'm not going to drive 1, but if someone wants to take lead I'll do what I can to support. As far as I can determine the -DUATOMIC_NO_LINK_ERROR merely causes the link error to be replaced with code that generates an illegal instruction (which will then trap at runtime). So it's just plastering over the compile time problem.
Found a Gentoo solution :-) Override bfd and use sys-devel/mold as linker with LDFLAGS="${LDFLAGS} -fuse-ld=mold" It compiles on a raspberry 2B (armv7a)
