Build issues on aarch64 Linux hosts

[msgilligan]

I've been trying to build OP-TEE with Rust on an aarch64 Linux host. (Mostly Debian Bookworm in a VM on MacBook M1)

I've run into at least three issues so far and made a PR for one of them:

• toolchain.mk: Rust toolchain is not downloaded on aarch64 hosts OP-TEE/build#749, with a fix PR Download Rust Toolchain during "make toolchains" on aarch64 hosts OP-TEE/build#748
• C++ tests fail on aarch64 hosts OP-TEE/build#751
• Compilation of Rust examples fails on aarch64 hosts OP-TEE/build#752

751 is not Rust-related, and is easily worked around with WITH_CXX_TESTS=n, but 752 is Rust-related and if anyone has any ideas on how to fix it, I would greatly appreciate hearing them.

[msgilligan]

We are making progress on this issue. Two of the three sub-issues above are now solved. Only OP-TEE/build#752 remains.

[msgilligan]

I have reproduced this issue by following the instructions in this project's README.md on an aarch64 Linux (Debian) machine.

See Related PR #137.

[msgilligan]

I have created a multi-architecture Dockerfile/containerFile that works correctly under AMD64 (x86_64) and exhibits the linker error we have been seeing under ARM64 (aarch64) and uploaded it in a gist:
https://gist.github.com/msgilligan/a36d61953d2caf60d33d233fed281c7b

Note that the exact error is ld.bfd: cannot find -lgcc_s: No such file or directory (In some earlier test configurations that I used the _s wasn't present.)

[msgilligan]

Note that since OP-TEE/build#764 (and related changes) were merged to OP-TEE/build RUST_ENABLE defaults to n.

I'm assuming that if we can fix this issue that OP-TEE/build can default to RUST_ENABLE=y again.

[b49020]

Thanks @msgilligan for continuously following this issue. It has been on my ToDo list. BTW, thanks for that docker fine which allowed me to reproduce it.

[msgilligan]

Thanks @msgilligan for continuously following this issue. It has been on my ToDo list. BTW, thanks for that docker fine which allowed me to reproduce it.

I really need this fixed as I'm trying to write a TA in Rust and my main development system is an ARM64 laptop (MacBook Pro M1 with Debian in a VM) so I am motivated to get it fixed. Unfortunately, I don't know much about Rust linking or the custom link options used for TAs.

I'm hoping this gets fixed by someone else, but I am willing to help with testing, documentation, or even coding a fix. Is there any documentation about the custom link options for TAs?

[ivila]

I have created a multi-architecture Dockerfile/containerFile that works correctly under AMD64 (x86_64) and exhibits the linker error we have been seeing under ARM64 (aarch64) and uploaded it in a gist: https://gist.github.com/msgilligan/a36d61953d2caf60d33d233fed281c7b

Note that the exact error is ld.bfd: cannot find -lgcc_s: No such file or directory (In some earlier test configurations that I used the _s wasn't present.)

Actually this is because ld.bfd do not find the gcc_s library, this is common on arm host machine, and cargo defaultly use gcc as linker instead of ld(yes, gcc solves the problem), so change the linker to gcc would work, or you might need to specific the path of gcc_s(trust me, this is painful).

I am going to provide a new crate optee-utee-build, I hope it will save us from struggle with compiling.

PS: If you change the linker to gcc, you might need to change some of the rustc-link-arg, add -Wl to tell gcc pass arguments to linker, for example cargo:rustc-link-arg=--dynamic-list=dyn_list changed to cargo:rustc-link-arg=-Wl,--dynamic-list=dyn_list