incubator-teaclave-trustzone-sdk icon indicating copy to clipboard operation
incubator-teaclave-trustzone-sdk copied to clipboard

Build issues on aarch64 Linux hosts

Open msgilligan opened this issue 1 year ago • 6 comments
trafficstars

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:

  • https://github.com/OP-TEE/build/issues/749, with a fix PR https://github.com/OP-TEE/build/pull/748
  • https://github.com/OP-TEE/build/issues/751
  • https://github.com/OP-TEE/build/issues/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 avatar May 22 '24 00:05 msgilligan

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

msgilligan avatar May 24 '24 17:05 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 avatar May 29 '24 03:05 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 avatar Jun 05 '24 19:06 msgilligan

Note that since https://github.com/OP-TEE/build/pull/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.

msgilligan avatar Jul 11 '24 00:07 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.

b49020 avatar Jul 11 '24 06:07 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.

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?

msgilligan avatar Jul 11 '24 16:07 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.)

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

ivila avatar Dec 19 '24 09:12 ivila