Building v on current Raspian 32-Bit (debian bulleye) fails

[WoodyAtHome]

On a fresh installed Raspberry Pi System (

uname -a
Linux homeserver 5.15.56-v7+ #1575 SMP Fri Jul 22 20:28:11 BST 2022 armv7l GNU/Linux

) make v fails:

pi@homeserver:~/v/v $ make
make fresh_vc
make[1]: Entering directory '/home/pi/v/v'
rm -rf ./vc
git clone --depth 1 --quiet --single-branch https://github.com/vlang/vc ./vc
make[1]: Leaving directory '/home/pi/v/v'
cd ./vc && git clean -xf && git pull --quiet
make fresh_tcc
make[1]: Entering directory '/home/pi/v/v'
rm -rf ./thirdparty/tcc
git clone --depth 1 --quiet --single-branch --branch thirdparty-linux-arm https://github.com/vlang/tccbin ./thirdparty/tcc
make[2]: Entering directory '/home/pi/v/v'
make[2]: Leaving directory '/home/pi/v/v'
make[1]: Leaving directory '/home/pi/v/v'
cd ./thirdparty/tcc && git clean -xf && git pull --quiet
cc  -std=gnu99 -w -o v1.exe ./vc/v.c -lm -lpthread 
/usr/bin/ld: /tmp/ccHB1E14.o: in function `atomic_load_u64':
v.c:(.text+0xb10): undefined reference to `__atomic_load_8'
/usr/bin/ld: /tmp/ccHB1E14.o: in function `atomic_store_u64':
v.c:(.text+0xb68): undefined reference to `__atomic_store_8'
/usr/bin/ld: /tmp/ccHB1E14.o: in function `atomic_fetch_add_u64':
v.c:(.text+0xb9c): undefined reference to `__atomic_fetch_add_8'
/usr/bin/ld: /tmp/ccHB1E14.o: in function `atomic_fetch_sub_u64':
v.c:(.text+0xbdc): undefined reference to `__atomic_fetch_sub_8'
collect2: error: ld returned 1 exit status
make: *** [GNUmakefile:96: all] Error 1

Adding a explicit -latomic would fix the problem:

pi@homeserver:~/v/v $  cc  -std=gnu99 -w -o v1.exe ./vc/v.c -lm -lpthread -latomic
pi@homeserver:~/v/v $  

workaround:

pi@homeserver:~/v/v $  export LDFLAGS="-latomic"
pi@homeserver:~/v/v $  make
cd ./vc && git clean -xf && git pull --quiet
cd ./thirdparty/tcc && git clean -xf && git pull --quiet
cc  -std=gnu99 -w -o v1.exe ./vc/v.c -lm -lpthread -latomic
./v1.exe -no-parallel -o v2.exe  cmd/v
./v2.exe -o ./v  cmd/v
rm -rf v1.exe v2.exe

Note: `tcc` was not used, so unless you install it yourself, your backend
C compiler will be `cc`, which is usually either `clang`, `gcc` or `msvc`.

These C compilers, are several times slower at compiling C source code,
compared to `tcc`. They do produce more optimised executables, but that
is done at the cost of compilation speed.

V has been successfully built
V 0.3.0 d75c62b
pi@homeserver:~/v/v $ v doctor
OS: linux, Raspbian GNU/Linux 11 (bullseye)
Processor: 4 cpus, 32bit, little endian, ARMv7 Processor rev 4 (v7l)
CC version: cc (Raspbian 10.2.1-6+rpi1) 10.2.1 20210110

getwd: /home/pi/v/v
vmodules: /home/pi/.vmodules
vroot: /home/pi/v/v
vexe: /home/pi/v/v/v
vexe mtime: 2022-08-27 13:23:01
is vroot writable: true
is vmodules writable: true
V full version: V 0.3.0 d75c62b

Git version: git version 2.30.2
Git vroot status: weekly.2022.34-38-gd75c62b8
.git/config present: true
thirdparty/tcc status: thirdparty-linux-arm b5dcedaa

[phcreery]

This workaround worked for me