Build error on RISC-V 64bits system

[OctopusET]

Error

When I was trying to build with make -j$(nproc) on riscv64(QEMU) Debian unstable, I get this error.

error: '__TBB_machine_fetchadd4' was not declared in this scope
348 | return __TBB_machine_fetchadd4(ptr, 1) + 1L;

I found similar error https://bugs.funtoo.org/browse/FL-8615?attachmentSortBy=fileName

Fix

• And I fixed with this patch

• Or using this patch would work too.

-    return __TBB_machine_fetchadd4(ptr, 1) + 1L;
+    return __atomic_fetch_add(ptr, 1L, __ATOMIC_SEQ_CST) + 1L;

And I got another error after patch.

undefined reference to `__atomic_exchange_1'

I fixed it with this.

-LIBS = -pthread -lz -ldl -lm
+LIBS = -pthread -lz -ldl -lm -latomic

Although those patches fix build error, but upstream onetbb does not require any patch when I was building on same system, it seems like they removed Arch specific code. I think updating onetbb to upstream will be better option.

References:

• Build failure on RISC-V due missing __atomic_exchange_1 advancedtelematic/aktualizr#1427
• https://stackoverflow.com/questions/35339514/undefined-reference-in-static-library-to-c11-atomic

[OctopusET]

Please let me know what would you think the best solution, I can make PR. Thanks

[rui314]

Thank you for testing this on RISC-V!

It looks like upgrading onetbb is the best option if it solves the problem for you and doesn't have any regression. Let me take a look.

[OctopusET]

Thank you for response!

Please let me know if there is anything I can do.

[rui314]

I updated our oneTBB subtree to v2021.5.0, the latest stable version of the library. Can you try again to see if it builds on RISC-V?

[OctopusET]

@rui314 Thank you for work.

Seems like v2021.5.0 does not including commit (uxlfoundation/oneTBB@6fad698), PR (uxlfoundation/oneTBB#550)

So it's not able to build. And adding -latomic on Makefile still needed.
But just patching above commit fixes build problem.

What about patching that commit until new stable version came out?

ps:
What about using submodule for handling third-party project? (like onetbb) I think it would be easier to maintain and update them.

[rui314]

Do you mind if I ask you to create a patch and send me a pull request? I can make a change for you, but I cannot verify that myself, so it is probably faster for you to fix it on your side and let me just merge your change.

As to subtree/submodule, I used to be managing third-party libraries as submodule, but subtree was easier for me to manage them. At least it is simpler than submodule.

[OctopusET]

@rui314 Sure, I will send PR soon, but I'd like to test mold on RISC-V. Will make test just work for basic test?

[rui314]

@OctopusET make test will run all tests. If you want to run only a few basic tests, please directly run test scripts in test/elf such as test/elf/hello-dynamic.sh.

[OctopusET]

@rui314 I've should test before, seems like mold does not support RISC-V elf.
Anyway build is now okay, so I will send PR soon.

[rui314]

I'd like to port mold to RV64 which shouldn't be too hard. Your patch is I think a first step towards that.

[aaronfranke]

Hi, which version of Mold added support for RISC-V? I want to be able to document the minimum required version.

[rui314]

mold got RISC-V support back in 2022. So all versions since the license was changed to MIT should support RISC-V. That being said, we've been fixing several issues since then, so I'm not sure if older versions would work fine in the modern environment. mold is still a relatively young project. I'd pick a fairly recent version (e.g. within one year) and recommend it as a minimum required version. Note that we do not support older versions other than the latest one and will not fix bugs for those versions.