RISC-V device unable to build properly (VisionFive2)

DSOE1024 commented 4 months ago

Tested versions

4.2.1-stable

System information

Debian11 Godot-4.2.1-stable

Issue description

Hello I compiled Godot on my RISC-V device (VisionFive2), the previous issue（https://github.com/godotengine/godot/issues/80676） said to use the clang compiler, but the program compiled by the clang compiler does not run normally (can only run headless mode)

Since the GCC compiler libatomic doesn't work properly seems to be that the atomic instructions of riscv64 are incomplete, it is necessary to add the -latomic parameter to gcc and install the libatomic library at compile time to fully support the features of atomic

user@starfive:~/godot$ gcc --version
gcc (Debian 12.2.0-10) 12.2.0
Copyright (C) 2022 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

user@starfive:~/godot$ scons --version
SCons by Steven Knight et al.:
        SCons: v4.4.0.fc8d0ec215ee6cba8bc158ad40c099be0b598297, Sat, 30 Jul 2022 14:11:34 -0700, by bdbaddog on M1Dog2021
        SCons path: ['/usr/lib/python3/dist-packages/SCons']
Copyright (c) 2001 - 2022 The SCons Foundation

user@starfive:~/godot$ sudo apt install libatomic1
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
libatomic1 is already the newest version (12.2.0-10).

If you are using GCC12 on VF2, the following error message is displayed:

In file included from ./core/os/memory.h:35,
                 from ./core/templates/local_vector.h:35,
                 from ./core/object/message_queue.h:36,
                 from ./core/object/object.h:35,
                 from ./core/variant/binder_common.h:35,
                 from ./core/object/method_bind.h:34,
                 from ./core/object/class_db.h:34,
                 from ./core/config/project_settings.h:34,
                 from platform/linuxbsd/crash_handler_linuxbsd.cpp:33:
./core/templates/safe_refcount.h:157:41: error: static assertion failed
  157 |         static_assert(std::atomic_bool::is_always_lock_free);
      |                       ~~~~~~~~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~
In file included from ./core/os/memory.h:35,
                 from ./core/templates/local_vector.h:35,
                 from ./core/object/message_queue.h:36,
                 from ./core/object/object.h:35,
                 from ./core/variant/binder_common.h:35,
                 from ./core/object/method_bind.h:34,
                 from ./core/object/class_db.h:34,
                 from ./core/object/ref_counted.h:34,
                 from ./core/io/resource_uid.h:34,
                 from ./core/io/resource.h:34,
                 from ./core/input/input_event.h:35,
                 from ./core/input/input.h:34,
                 from platform/linuxbsd/joypad_linux.h:36,
                 from platform/linuxbsd/os_linuxbsd.h:35,
                 from platform/linuxbsd/godot_linuxbsd.cpp:31:
./core/templates/safe_refcount.h:157:41: error: static assertion failed
  157 |         static_assert(std::atomic_bool::is_always_lock_free);
      |                       ~~~~~~~~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~
In file included from ./core/os/memory.h:35,
                 from ./core/templates/local_vector.h:35,
                 from ./core/object/message_queue.h:36,
                 from ./core/object/object.h:35,
                 from ./core/variant/binder_common.h:35,
                 from ./core/object/method_bind.h:34,
                 from ./core/object/class_db.h:34,
                 from ./core/object/ref_counted.h:34,
                 from ./core/io/resource_uid.h:34,
                 from ./core/io/resource.h:34,
                 from ./core/input/input_event.h:35,
                 from ./core/input/input.h:34,
                 from platform/linuxbsd/joypad_linux.h:36,
                 from platform/linuxbsd/joypad_linux.cpp:33:
./core/templates/safe_refcount.h:157:41: error: static assertion failed
  157 |         static_assert(std::atomic_bool::is_always_lock_free);
      |                       ~~~~~~~~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~
In file included from ./core/os/memory.h:35,
                 from ./core/templates/local_vector.h:35,
                 from ./core/object/message_queue.h:36,
                 from ./core/object/object.h:35,
                 from ./core/variant/binder_common.h:35,
                 from ./core/object/method_bind.h:34,
                 from ./core/object/class_db.h:34,
                 from ./core/object/ref_counted.h:34,
                 from ./core/io/resource_uid.h:34,
                 from ./core/io/resource.h:34,
                 from ./core/input/input_event.h:35,
                 from ./core/input/input.h:34,
                 from platform/linuxbsd/joypad_linux.h:36,
                 from platform/linuxbsd/os_linuxbsd.h:35,
                 from platform/linuxbsd/os_linuxbsd.cpp:31:
./core/templates/safe_refcount.h:157:41: error: static assertion failed
  157 |         static_assert(std::atomic_bool::is_always_lock_free);
      |                       ~~~~~~~~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~
scons: *** [platform/linuxbsd/crash_handler_linuxbsd.linuxbsd.editor.rv64.o] Err                                                                                                             or 1
scons: *** [platform/linuxbsd/joypad_linux.linuxbsd.editor.rv64.o] Error 1
scons: *** [platform/linuxbsd/godot_linuxbsd.linuxbsd.editor.rv64.o] Error 1
scons: *** [platform/linuxbsd/os_linuxbsd.linuxbsd.editor.rv64.o] Error 1
scons: building terminated because of errors.
[Time elapsed: 00:00:23.511]

This is probably caused by Godot's compilation ignoring atomic under riscv64, hope this build issue can be fixed, thanks

Steps to reproduce

scons platform=linuxbsd target=editor

Minimal reproduction project (MRP)

N/A

bruvzg commented 4 months ago

Adding -latomic to GCC won't do much since it still using GCC headers and CRT. You can try building a single-thread version (threads=no flag).

But even if you can build it, GPU drivers on VisionFive2 are garbage and completely unusable, so it Godot won't run as is (the only way to run anything is removing GPU drivers and replacing with Mesa software OpenGL implementation).

DSOE1024 commented 4 months ago

Adding -latomic to GCC won't do much since it still using GCC headers and CRT. You can try building a single-thread version (threads=no flag).

But even if you can build it, GPU drivers on VisionFive2 are garbage and completely unusable, so it Godot won't run as is (the only way to run anything is removing GPU drivers and replacing with Mesa software OpenGL implementation).

Hello, thank you very much, I will try. Regarding this GPU (IMG BXE-4-32 MC1) of the VF2 board, it can run vulkan, but there seems to be a problem with the driver, do you need to wait for the driver of vulkan to be perfected? Is there a way to get Godot to use GLES drivers like on an ARM board device?

bruvzg commented 4 months ago

Is there a way to get Godot to use GLES drivers like on an ARM board device?

Run with --rendering-method compatibility --rendering-driver opengl3_es, but last time I have tested it (a few months ago), GLES driver was as broken as the rest.

DSOE1024 commented 4 months ago

Adding -latomic to GCC won't do much since it still using GCC headers and CRT. You can try building a single-thread version (threads=no flag).

But even if you can build it, GPU drivers on VisionFive2 are garbage and completely unusable, so it Godot won't run as is (the only way to run anything is removing GPU drivers and replacing with Mesa software OpenGL implementation).

Hello, I tried this, but the problem persists, I replaced VF2 with Arch's image, GCC version is 13, and the compilation works fine

However, I copied the compiled file to the debian image of VF2 (the official desktop version), but the error "Segmentation fault" (the Arch image can be run but not graphical) may be the reason, thanks !

godotengine / godot