`make` stuck under ARM/Linux

[kbkpbot]

Describe the bug

When try to make create a v under ARM Linux, it will stuck at v2 stage.

Reproduction Steps

make

Expected Behavior

create a new v.

Current Behavior

make stuck at v2 stage.

$ make
cd ./vc && git clean -xf && git pull --quiet
remote: Enumerating objects: 2, done.
remote: Counting objects: 100% (2/2), done.
remote: Compressing objects: 100% (2/2), done.
remote: Total 2 (delta 1), reused 0 (delta 0), pack-reused 0 (from 0)
接收对象中: 100% (2/2), 1.04 MiB | 360.00 KiB/s, 完成.
处理 delta 中: 100% (1/1), 完成.
正在更新文件: 100% (2/2), 完成.
cd ./thirdparty/tcc && git clean -xf && git pull --quiet
cc  -std=gnu99 -w -o v1 ./vc/v.c -lm -lpthread  || cmd/tools/cc_compilation_failed_non_windows.sh
./v1 -no-parallel -o v2  cmd/v
./v2 -nocache -o ./v  cmd/v

Possible Solution

By editing the GNUMakefile, add a -no-parallel flag to the v2 command, it will create a new v successful.

$ make
cd ./vc && git clean -xf && git pull --quiet
cd ./thirdparty/tcc && git clean -xf && git pull --quiet
cc  -std=gnu99 -w -o v1 ./vc/v.c -lm -lpthread  || cmd/tools/cc_compilation_failed_non_windows.sh
./v1 -no-parallel -o v2  cmd/v
./v2 -nocache -no-parallel -o ./v  cmd/v
rm -rf v1 v2

But v repl can't start...

Additional Information/Context

It may related to the parallel compiling under ARM/Linux

V version

V 0.4.9 89d1aac

Environment details (OS name and version, etc.)

V full version	V 0.4.9 a694918.89d1aac
OS	linux, Ubuntu 20.04.6 LTS
Processor	4 cpus, 64bit, little endian, aarch64
Memory	0.61GB/3.78GB
V executable	/home/vpn/github/lang/v/v_old
V last modified time	2025-02-23 11:35:00
V home dir	OK, value: /home/vpn/github/lang/v
VMODULES	OK, value: /home/vpn/.vmodules
VTMP	OK, value: /tmp/v_1001
Current working dir	OK, value: /home/vpn/github/lang/v
Git version	git version 2.25.1
V git status	weekly.2025.11-22-g17695801-dirty
.git/config present	true
cc version	cc (Ubuntu 9.4.0-1ubuntu1~20.04.2) 9.4.0
gcc version	gcc (Ubuntu 9.4.0-1ubuntu1~20.04.2) 9.4.0
clang version	clang version 10.0.0-4ubuntu1
tcc version	tcc version 0.9.27 mob:da11cf6 (AArch64 Linux)
tcc git status	thirdparty-linux-aarch64 ecc2f67a
emcc version	N/A
glibc version	ldd (Ubuntu GLIBC 2.31-0ubuntu9.17) 2.31

Note

You can use the 👍 reaction to increase the issue's priority for developers.

Please note that only the 👍 reaction to the issue itself counts as a vote.
Other reactions and those to comments will not be taken into account.

[huly-for-github]

Connected to Huly®: V_0.6-22323

[medvednikov]

Yes, can reproduce.

[kbkpbot]

I found the root cause of this bug, it is because I use a old version of tcc. By upgrading tcc to latest version, it solve this bug.

Because the old version of tcc has some bug in atomic operation.

How to verify:
modify the vlib/sync/pool/pool.c.v:

// process_in_thread does the actual work of worker thread.
// It is a workaround for the current inability to pass a
// method in a callback.
fn process_in_thread(mut pool PoolProcessor, task_id int) {
        cb := ThreadCB(pool.thread_cb)
        ilen := pool.items.len
        for {
                dump(pool.ntask)
                idx := int(C.atomic_fetch_add_u32(&pool.ntask, 1))
                dump(idx)                       // idx should be pool.ntask+1
                if idx >= ilen {
                        break
                }
                pool.results[idx] = cb(mut pool, idx, task_id)
        }
        pool.waitgroup.done()
}

then make,

old version tcc produce:

$ make
cd ./vc && git clean -xf && git pull --quiet
cd ./thirdparty/tcc && git clean -xf && git pull --quiet
cc  -std=gnu99 -w -o v1 ./vc/v.c -lm -lpthread  || cmd/tools/cc_compilation_failed_non_windows.sh
./v1 -no-parallel -o v2  cmd/v
./v2 -nocache -showcc -keepc -o ./v  cmd/v
[/home/vpn/github/lang/v/vlib/sync/pool/pool.c.v:114] pool.ntask: 0
[/home/vpn/github/lang/v/vlib/sync/pool/pool.c.v:116] idx: 10199400
[/home/vpn/github/lang/v/vlib/sync/pool/pool.c.v:114] pool.ntask: 0
[/home/vpn/github/lang/v/vlib/sync/pool/pool.c.v:116] idx: 10199400
[/home/vpn/github/lang/v/vlib/sync/pool/pool.c.v:114] pool.ntask: 0
[/home/vpn/github/lang/v/vlib/sync/pool/pool.c.v:116] idx: 10199400
``

[medvednikov]

Great find!

@spytheman how can we always use the latest version of tcc?

Recent FreeBSD issues were also caused by an old version of tcc.

[spytheman]

I've added thirdparty/build_scripts/ in 86bb2d7 to make it easier to update the prebuilt tcc executables. I am currently working on a script for windows too, based on vlang/tccbin#57 , since the PR unfortunately does not include all the patches for the .def and .h files, that we did after building tcc on windows the last time.

[spytheman]

I.e. the main idea is to have a set of scripts, in the main V repo, that can be run directly, to built locally a working tcc and libgc from their latest versions (or from a specific commit), without further manual input.

[kbkpbot]

I found the root cause of this bug, it is because I use a old version of tcc. By upgrading tcc to latest version, it solve this bug.

Because the old version of tcc has some bug in atomic operation.

How to verify: modify the vlib/sync/pool/pool.c.v:

// process_in_thread does the actual work of worker thread.
// It is a workaround for the current inability to pass a
// method in a callback.
fn process_in_thread(mut pool PoolProcessor, task_id int) {
cb := ThreadCB(pool.thread_cb)
ilen := pool.items.len
for {
dump(pool.ntask)
idx := int(C.atomic_fetch_add_u32(&pool.ntask, 1))
dump(idx) // idx should be pool.ntask+1
if idx >= ilen {
break
}
pool.results[idx] = cb(mut pool, idx, task_id)
}
pool.waitgroup.done()
}
then make,

old version tcc produce:

$ make
cd ./vc && git clean -xf && git pull --quiet
cd ./thirdparty/tcc && git clean -xf && git pull --quiet
cc  -std=gnu99 -w -o v1 ./vc/v.c -lm -lpthread  || cmd/tools/cc_compilation_failed_non_windows.sh
./v1 -no-parallel -o v2  cmd/v
./v2 -nocache -showcc -keepc -o ./v  cmd/v
[/home/vpn/github/lang/v/vlib/sync/pool/pool.c.v:114] pool.ntask: 0
[/home/vpn/github/lang/v/vlib/sync/pool/pool.c.v:116] idx: 10199400
[/home/vpn/github/lang/v/vlib/sync/pool/pool.c.v:114] pool.ntask: 0
[/home/vpn/github/lang/v/vlib/sync/pool/pool.c.v:116] idx: 10199400
[/home/vpn/github/lang/v/vlib/sync/pool/pool.c.v:114] pool.ntask: 0
[/home/vpn/github/lang/v/vlib/sync/pool/pool.c.v:116] idx: 10199400
``

I post a bug in [Tinycc-devel] maillist, hope it can be solved by someone.
https://lists.nongnu.org/archive/html/tinycc-devel/2025-05/msg00010.html

BTW, this bug still exist in latest tcc.

A workaround for this , is remove following from vlib/sync/stdatomic/1.declarations.c.v

		} $else $if arm64 {
			// Debian/Ubuntu:
			#flag $when_first_existing('/usr/lib/gcc/aarch64-linux-gnu/6/libatomic.a','/usr/lib/gcc/aarch64-linux-gnu/7/libatomic.a','/usr/lib/gcc/aarch64-linux-gnu/8/libatomic.a','/usr/lib/gcc/aarch64-linux-gnu/9/libatomic.a','/usr/lib/gcc/aarch64-linux-gnu/10/libatomic.a','/usr/lib/gcc/aarch64-linux-gnu/11/libatomic.a','/usr/lib/gcc/aarch64-linux-gnu/12/libatomic.a','/usr/lib/gcc/aarch64-linux-gnu/13/libatomic.a','/usr/lib/gcc/aarch64-linux-gnu/14/libatomic.a')
			// Redhat/CentOS:
			#flag $when_first_existing('/usr/lib/gcc/aarch64-redhat-linux/6/libatomic.a','/usr/lib/gcc/aarch64-redhat-linux/7/libatomic.a','/usr/lib/gcc/aarch64-redhat-linux/8/libatomic.a','/usr/lib/gcc/aarch64-redhat-linux/9/libatomic.a','/usr/lib/gcc/aarch64-redhat-linux/10/libatomic.a','/usr/lib/gcc/aarch64-redhat-linux/11/libatomic.a','/usr/lib/gcc/aarch64-redhat-linux/12/libatomic.a','/usr/lib/gcc/aarch64-redhat-linux/13/libatomic.a','/usr/lib/gcc/aarch64-redhat-linux/14/libatomic.a')
			// Gentoo:
			#flag $when_first_existing('/usr/lib/gcc/aarch64-pc-linux-gnu/6/libatomic.a','/usr/lib/gcc/aarch64-pc-linux-gnu/7/libatomic.a','/usr/lib/gcc/aarch64-pc-linux-gnu/8/libatomic.a','/usr/lib/gcc/aarch64-pc-linux-gnu/9/libatomic.a','/usr/lib/gcc/aarch64-pc-linux-gnu/10/libatomic.a','/usr/lib/gcc/aarch64-pc-linux-gnu/11/libatomic.a','/usr/lib/gcc/aarch64-pc-linux-gnu/12/libatomic.a','/usr/lib/gcc/aarch64-pc-linux-gnu/13/libatomic.a','/usr/lib/gcc/aarch64-pc-linux-gnu/14/libatomic.a')
			// OpenSUSE:
			#flag $when_first_existing('/usr/lib64/gcc/aarch64-suse-linux/6/libatomic.a','/usr/lib64/gcc/aarch64-suse-linux/7/libatomic.a','/usr/lib64/gcc/aarch64-suse-linux/8/libatomic.a','/usr/lib64/gcc/aarch64-suse-linux/9/libatomic.a','/usr/lib64/gcc/aarch64-suse-linux/10/libatomic.a','/usr/lib64/gcc/aarch64-suse-linux/11/libatomic.a','/usr/lib64/gcc/aarch64-suse-linux/12/libatomic.a','/usr/lib64/gcc/aarch64-suse-linux/13/libatomic.a','/usr/lib64/gcc/aarch64-suse-linux/14/libatomic.a')
			// ALT Linux:
			#flag $when_first_existing('/usr/lib64/gcc/aarch64-alt-linux/6/libatomic.a','/usr/lib64/gcc/aarch64-alt-linux/7/libatomic.a','/usr/lib64/gcc/aarch64-alt-linux/8/libatomic.a','/usr/lib64/gcc/aarch64-alt-linux/9/libatomic.a','/usr/lib64/gcc/aarch64-alt-linux/10/libatomic.a','/usr/lib64/gcc/aarch64-alt-linux/11/libatomic.a','/usr/lib64/gcc/aarch64-alt-linux/12/libatomic.a','/usr/lib64/gcc/aarch64-alt-linux/13/libatomic.a','/usr/lib64/gcc/aarch64-alt-linux/14/libatomic.a')
			$if musl ? {
				// Alpine:
				#flag $when_first_existing('/usr/lib/libatomic.a','/usr/lib/gcc/aarch64-pc-linux-musl/6/libatomic.a','/usr/lib/gcc/aarch64-pc-linux-musl/7/libatomic.a','/usr/lib/gcc/aarch64-pc-linux-musl/8/libatomic.a','/usr/lib/gcc/aarch64-pc-linux-musl/9/libatomic.a','/usr/lib/gcc/aarch64-pc-linux-musl/10/libatomic.a','/usr/lib/gcc/aarch64-pc-linux-musl/11/libatomic.a','/usr/lib/gcc/aarch64-pc-linux-musl/12/libatomic.a','/usr/lib/gcc/aarch64-pc-linux-musl/13/libatomic.a','/usr/lib/gcc/aarch64-pc-linux-musl/14/libatomic.a')
			}
		}