On a Raspberry Pi 3 v1.2, and also on I think a Zero W v1.1, but probably all RPis running Raspbian 10 'Buster', the build fails to link atomic -- undefined reference to __atomic_fetch_add_8'

uname: Linux raspberrypi 4.19.57-v7+ #1244 SMP Thu Jul 4 18:45:25 BST 2019 armv7l GNU/Linux`
gcc --version: gcc (Raspbian 8.3.0-6+rpi1) 8.3.0

This is easily fixed by 'hacking' a -latomic in to the build flags, though I'm not too familiar with the Makefile and where best to add such a link without breaking stuff, so haven't PR'd

Redis 5.0.4
    ...
    CC t_stream.o
    CC localtime.o
    CC lolwut.o
    CC lolwut5.o
    LINK redis-server
/usr/bin/ld: networking.o: in function `createClient':
/home/pi/Downloads/redis-5.0.4/src/networking.c:108: undefined reference to `__atomic_fetch_add_8'
collect2: error: ld returned 1 exit status
make[1]: *** [Makefile:219: redis-server] Error 1
make[1]: Leaving directory '/home/pi/Downloads/redis-5.0.4/src'
make: *** [Makefile:9: install] Error 2

This seems similar to #5550

Comment From: LucidSkyWalker

Adding "-latomic" as library is correct. I just modified the Makefile (under the "src" directory) and it works. Change: FINAL_LIBS=-lm To: FINAL_LIBS=-lm -latomic

I hope it helps

Comment From: qpernil

Any progress on this one ? It still doesn't build...

Comment From: AngusP

@qpernil unfortunately I've not had time to see how best to propose a fix that won't also potentially break other Redis builds...

However, if you edit src/Makefile and add -latomic to line 77, so that it looks like this:

 72   |  # Override default settings if possible
 73   |  -include .make-settings
 74   |  
 75   |  FINAL_CFLAGS=$(STD) $(WARN) $(OPT) $(DEBUG) $(CFLAGS) $(REDIS_CFLAGS)
 76   |  FINAL_LDFLAGS=$(LDFLAGS) $(REDIS_LDFLAGS) $(DEBUG)
*77*  |  FINAL_LIBS=-lm -latomic
 78   |  DEBUG=-g -ggdb
 79   |  
 80   |  ifeq ($(uname_S),SunOS)

and then run make again, it should work for you.

Comment From: qpernil

OK, Thanks @AngusP

Comment From: mibere

Had the same issue. But I can confirm that the compilation of Redis 5.0.7 on Raspbian 10 (Buster) is successful after changing

FINAL_LIBS=-lm

to

FINAL_LIBS=-lm -latomic

in src/Makefile

Comment From: qpernil

Yes, I can also confirm it works.

Comment From: antirez

Please @qpernil could you try if instead of using -latomic directly there, it works with the following patch?

diff --git a/src/Makefile b/src/Makefile
index 9fc230f9..e6773198 100644
--- a/src/Makefile
+++ b/src/Makefile
@@ -77,6 +77,15 @@ FINAL_LDFLAGS=$(LDFLAGS) $(REDIS_LDFLAGS) $(DEBUG)
 FINAL_LIBS=-lm
 DEBUG=-g -ggdb

+# Linux ARM needs -latomic at linking time
+ifneq (,$(filter aarch64 armv,$(uname_M)))
+        FINAL_LIBS+=-latomic
+else
+ifneq (,$(findstring armv,$(uname_M)))
+        FINAL_LIBS+=-latomic
+endif
+endif
+
 ifeq ($(uname_S),SunOS)
        # SunOS
         ifneq ($(@@),32bit)

Thank you

Comment From: antirez

ping @LucidSkyWalker to see if it's possible to get the patch tested. The problem is that I don't want it to break other builds. Right now my Pi3 looks dead unfortunately, I'll have to resurrect it.

Comment From: AngusP

@antirez I’ve also got a handful of Pis, just not found time to test it yet, will try and do so soon if I don’t get beaten to it

Comment From: antirez

Thanks a lot @AngusP :-) I'll try to resurrect mine at the same time to have a larger test base, especially since I believe I've a version of the distribution that does not need -latomic, to check if it may create problems in that case.

Comment From: itamarhaber

+@rafie may be able to help too.

Comment From: AngusP

So, build succeeds and tests pass on all the Pis I have access to :champagne: (well, except some tests time out sometimes)

All running Raspbian 10, building the 5.0.7 release with the above Makefile patch given by @antirez.

on a Pi 4 Model B (BCM2835 rev. c03111quad core, 4GB RAM) uname -a = Linux raspberrypi 4.19.50-v7l+ #895 SMP Thu Jun 20 16:03:42 BST 2019 armv7l GNU/Linux

on a Pi ZeroW v1.1 (BCM2835 rev. 9000c1 single core) (this took a while!) uname -a = Linux raspberrypi 4.19.57+ #1244 Thu Jul 4 18:42:50 BST 2019 armv6l GNU/Linux

on a Pi 3 Model B v1.2 (BCM2835 rev. a22082 quad core) uname -a = Linux raspberrypi 4.19.66-v7+ #1253 SMP Thu Aug 15 11:49:46 BST 2019 armv7l GNU/Linux

Comment From: antirez

Thanks @AngusP! Fix pushed.

Comment From: qpernil

Sorry for not finding time to help with this... Next time..

Comment From: antirez

Sorry for not finding time to help with this... Next time..

Thanks anyway!

Comment From: qpernil

Hi Salvatore,

I have now tested this on a Raspberry pi 3B+ and a 4B (2Gb), both running Buster. It worked perfectly.

I also applied the patch on Catalina 10.15.1, and Ubuntu eoan with no ill effects (I ran make test on all four machines).

Thanks ! /Per

Comment From: jibp

不幸的是，@ qpernil我还没来得及看看如何最好地提出一个修补程序，该修补程序也不会破坏其他Redis版本...

但是，如果您编辑src/Makefile并添加-latomic到第77行，则它看起来像这样：

72 | # Override default settings if possible 73 | -include .make-settings 74 | 75 | FINAL_CFLAGS=$(STD) $(WARN) $(OPT) $(DEBUG) $(CFLAGS) $(REDIS_CFLAGS) 76 | FINAL_LDFLAGS=$(LDFLAGS) $(REDIS_LDFLAGS) $(DEBUG) *77* | FINAL_LIBS=-lm -latomic 78 | DEBUG=-g -ggdb 79 | 80 | ifeq ($(uname_S),SunOS)

然后make再次运行，它将为您工作。

只要修改src/Makefile 中的 FINAL_LIBS=-lm -latomic 就能运行了 亲测有用

Comment From: qpernil

Is this merged into any other branch than unstable ? /Per

Comment From: dustinmm80

Is this merged into any other branch than unstable ? /Per

It doesn't look like it this has been merged into 5.0 branch.

GitLab is mirroring this repository, the gitlab-omnibus installer uses this mirror as a dependency. We are seeing this sameundefined reference to __atomic_fetch_add_8 issue building redis 5 on Raspbian 10 Buster on ARM.

@AngusP do you intend to backport this fix to 5.0 branch? If that is your intention, but you're short on time I am happy to create the PR. Maybe we should reopen this issue.

Comment From: AngusP

@dustinmm80 as far as I can see it'd be fine to backport to any maintained version as it's just a Makefile fix (e9564dc); go ahead if you'd like it, I am a little short on time unfortunately