Compile v error in arm32 with debian 11 system

[Blackrose]

Hi, I try to compile v in arm32 platform with debian os. When I run make, it shows no found v file. So I try to run command by manual.

root@localhost:/v# 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
Receiving objects: 100% (2/2), 914.37 KiB | 45.00 KiB/s, done.
Resolving deltas: 100% (1/1), done.
Updating files: 100% (2/2), done.
cd ./thirdparty/tcc && git clean -xf && git pull --quiet
The executable './thirdparty/tcc/tcc.exe' does not work.
cc  -std=gnu99 -w -o v1.exe ./vc/v.c -lm -lpthread
./v1.exe -no-parallel -o v2.exe  cmd/v
No input .v files
make: *** [GNUmakefile:114: all] Error 1
root@localhost:/v# ls cmd/v/
v.v
root@localhost:/v# ./v1.exe -no-parallel -o v2.exe cmd/v/
No input .v files
root@localhost:/v# ./v1.exe -no-parallel -o v2.exe cmd/v/v.v
cmd/v/v.v:6:1: builder error: cannot import module "os" (no .v files in "/v/vlib/os")
    4 | module main
    5 |
    6 | import os
      | ~~~~~~~~~
    7 | import term
    8 | import v.help

[prantlf]

Might there be a problem with building V on 32-bit architectures?

On Linux, the build succeeds on amd64, arm64 and riscv64 targets. And that with both tcc and gcc. But when trying to build V on i386, armv6l and armv7l targets, the build fails. I worked around it with gcc and use_bundled_libgc, but I got it built only on i386.

i386

As soon as I noticed this error:

...
#9 3.150 The executable './thirdparty/tcc/tcc.exe' does not work.
#9 3.152 cc  -std=gnu99 -w -o v1.exe ./vc/v.c -lm -lpthread 
#9 13.94 ./v1.exe -no-parallel -o v2.exe  cmd/v
#9 26.25 ./v2.exe -nocache -o ./v  cmd/v
#9 38.44 rm -rf v1.exe v2.exe
#9 39.33 ================== C compilation error (from tcc): ==============
#9 39.33 cc: sh: 1: /opt/vlang/thirdparty/tcc/tcc.exe: not found

I engaged the trusty GNU C:

CC=gcc VFLAGS="-cc gcc" make

The message about tcc not working remained. Apparently it's being built although I picked gcc. Never mind. gcc was was picked and the compilation part succeeded. But linking failed. The last error message became this:

...
#9 38.16 cc: /usr/bin/ld: i386:x86-64 architecture of input file
               `/opt/vlang/thirdparty/tcc/lib/libgc.a(pthread_start.o)'
               is incompatible with i386 output

Why is it linking thirdparty/tcc/lib/libgc.a? And that after tcc build failed? I didn't set -d use_bundled_libgc. Shouldn't the gc library from the platform be used?

I tried the bundled gc:

CC=gcc VFLAGS="-cc gcc -d use_bundled_libgc" make

And job done! The i386 target is cleared.

ARM v6

tcc failed, but differently than for @Blackrose:

#12 [stage-6  8/10] RUN make
#12 1.404 make fresh_vc
#12 1.444 make[1]: Entering directory '/opt/vlang'
#12 2.703 rm -rf ./vc
#12 2.735 git clone --filter=blob:none --quiet https://github.com/vlang/vc ./vc
#12 6.491 make[1]: Leaving directory '/opt/vlang'
#12 6.495 cd ./vc && git clean -xf && git pull --quiet
#12 7.659 make fresh_tcc
#12 7.697 make[1]: Entering directory '/opt/vlang'
#12 8.959 rm -rf ./thirdparty/tcc
#12 8.990 git clone --filter=blob:none --quiet --branch thirdparty-linux-arm https://github.com/vlang/tccbin ./thirdparty/tcc
#12 11.57 make[2]: Entering directory '/opt/vlang'
#12 12.87 make[2]: Leaving directory '/opt/vlang'
#12 12.88 make[1]: Leaving directory '/opt/vlang'
#12 12.88 cd ./thirdparty/tcc && git clean -xf && git pull --quiet
#12 15.45 cc  -std=gnu99 -w -o v1.exe ./vc/v.c -lm -lpthread 
#12 109.6 /usr/bin/ld: /tmp/ccnBE8Zx.o: in function `atomic_load_u64':
#12 109.6 v.c:(.text+0xc68): undefined reference to `__atomic_load_8'
#12 109.6 /usr/bin/ld: /tmp/ccnBE8Zx.o: in function `atomic_store_u64':
#12 109.6 v.c:(.text+0xcc0): undefined reference to `__atomic_store_8'
#12 109.6 /usr/bin/ld: /tmp/ccnBE8Zx.o: in function `atomic_fetch_add_u64':
#12 109.6 v.c:(.text+0xcf4): undefined reference to `__atomic_fetch_add_8'
#12 109.6 /usr/bin/ld: /tmp/ccnBE8Zx.o: in function `atomic_fetch_sub_u64':
#12 109.6 v.c:(.text+0xd34): undefined reference to `__atomic_fetch_sub_8'
#12 109.7 collect2: error: ld returned 1 exit status
#12 109.7 make: *** [GNUmakefile:113: all] Error 1

But the failure didn't disappear when repeating the trick from i386. Although I thought that -DGC_BUILTIN_ATOMIC=1 would deal with the libatomic problem too:

CC=gcc VFLAGS="-cc gcc -d use_bundled_libgc" make
...
the same error

I tried compiling and linking the bundled libatomic by a new option:

diff --git a/vlib/builtin/builtin_d_gcboehm.c.v b/vlib/builtin/builtin_d_gcboehm.c.v
index 161a6de8f..23788e858 100644
--- a/vlib/builtin/builtin_d_gcboehm.c.v
+++ b/vlib/builtin/builtin_d_gcboehm.c.v
@@ -8,6 +8,14 @@ $if use_bundled_libgc ? {
        #flag @VEXEROOT/thirdparty/libgc/gc.o
 }

+$if use_bundled_libatomic ? {
+       #flag @VEXEROOT/thirdparty/libatomic_ops/atomic_ops.o
+       #flag -I @VEXEROOT/thirdparty/libatomic_ops
+
+       #flag -I @VEXEROOT/thirdparty/libgc/include
+       #flag @VEXEROOT/thirdparty/libgc/gc.o
+}
+
 $if dynamic_boehm ? {
        $if windows {
                $if tinyc {

But strangely, it still couldn't find the exports, just like in the previous runs:

#12 [stage-6  8/10] RUN CC=gcc VFLAGS="-cc gcc -d use_bundled_libatomic" make
...
the same error

ARM v7

I tried all what I did for ARMV v6, but I kept getting the same error as @Blackrose:

...
#12 11.59 gcc  -std=gnu99 -w -o v1.exe ./vc/v.c -lm -lpthread 
#12 137.8 ./v1.exe -no-parallel -o v2.exe -cc gcc cmd/v
#12 137.9 No input .v files
#12 137.9 make: *** [GNUmakefile:114: all] Error 1

Status

Architecture	Result
i386	built with gcc and -d use_bundled_libgc
armv6l	failed, exports from libatomic were missing
armv7l	failed, .v files couldn't be accessed

Is the solution for the i386 architecture correct? Does the build for armv6l and armv7l architectures work?

[JalonSolov]

When compiling V for 32-bit targets, you either need to add the -m32 switch, or -target arm32 or whatever to specify the output target. In fact, it may need some combination of extra options.

This means, of course, that you can't use the default Makefile without modifying it to add one or more of those options.

While it may be possible to have make figure out what you need, it hasn't been a big enough issue to build that in, yet.

People simply haven't been doing a lot with 32-bit systems with V, as most systems in the past 10+ years have been 64-bit. If you do find a nice way of handling 32-bit systems, please don't hesitate to submit a PR to help improve V.

[prantlf]

Thanks for the hint! So, there's some extra work expected. I'll look at what I can do.

I admit than 32-bit systems are on the decline. I've just received an older Raspberry Pi and an embedded PC with Vortex86 and I'm trying to get some services running on them. Node.js works, Zig too, Rust crashes and now I'm trying to get V working.

[jorgeluismireles]

I was able to install v in a raspberry pi :-) by making first LDFLAGS="-latomic" to prevent the errors mentioned above like atomic_load_u64.

Tried first sudo apt-get install -y libatomic-ops-dev though was installed already as /usr/lib/arm-linux-gnueabihf/libatomic.so.1.2.0.

It took minutes to finish but worked.

LDFLAGS="-latomic" make

dev@raspberrypi:~/v $ LDFLAGS="-latomic" 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 -nocache -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.4.8 2b546c4
dev@raspberrypi:~/v $ ./v run examples/hello_world.v 
Hello, World!
dev@raspberrypi:~/v $ 

tcc.exe actually was installed ok and runs in 32 bit mode ok though, will try to use it...

[jorgeluismireles]

I suspect tcc was not used because GNUMakefile has no the TCCARCH set for raspberry armv7l:

dev@raspberrypi:~/v $ uname -m
armv7l

[jorgeluismireles]

dev@raspberrypi:~/v $ thirdparty/tcc/tcc.exe --version
tcc version 0.9.27 - 0378168 (ARM eabihf Linux)

[jorgeluismireles]

In the arm7 with a more complex program than Hello world I got several tcc.exe errors and warnings about "garbage collector". I didn't write the details yesterday and only get from my browser history this error:

tcc: error: undefined symbol '__aeabi_unwind_cpp_pr1'

Was like something mixed with c/c++. I decided to download tcc directly from github, rename tcc.exe (to prevent being called) and the problems were solved:

dev@raspberrypi:~ $ tcc -version
tcc version 0.9.28rc 2024-09-27 mob@3ead10dd (ARM eabihf Linux)

Is weird since seems tcc.exe was "repaired" by installing tcc from github. Or maybe several software and libraries updates helped also.

[larpon]

Also rpi experiences documented here: https://gist.github.com/larpon/998febd5f3c33f995f0ecd561c043dcb