Build OpenThread `.a` libs without sysroot

[ivmarkov]

Basically, the equivalent of this issue in esp-mbedtls which is being built currently the exact same way as OpenThread: esp-rs/mbedtls-rs#98

Look at the above linked issue for more details.

[scootermon]

I took a stab at this to make my life easier while hacking on something else, and I managed to get it to compile using https://github.com/inomotech-foss/openthread/tree/556e76558d68f676d65ae8d98a1f902e75f8dcc3/openthread-sys/gen/sysroot/include
. Unfortunately, it requires quite a few more headers than mbedtls. I'm thinking we could benefit from a shared sysroot that could be added to a crate like embuild in the future.

This isn’t quite ready yet, though. For example, the assert macro is used heavily throughout openthread’s codebase, and right now I’m just defining it as #define assert(expr) (void)0. We’ll likely want to provide a proper assert mechanism instead—possibly with some Rust glue.

I’ll open a PR once I’ve had time to clean this up, but if anyone else wants to give it a go in the meantime, feel free to!

[ivmarkov]

I took a stab at this to make my life easier while hacking on something else, and I managed to get it to compile using https://github.com/inomotech-foss/openthread/tree/556e76558d68f676d65ae8d98a1f902e75f8dcc3/openthread-sys/gen/sysroot/include . Unfortunately, it requires quite a few more headers than mbedtls.

That's to be expected and I don't think this is a problem per se.
I have yet to look at your fake sysroot, but hopefully it won't use any IO functions you have provided the signatures of (if you did) at link time, as our openthread is compiled completely headless.

I'm thinking we could benefit from a shared sysroot that could be added to a crate like embuild in the future.

Yes. also my idea for the future. But I think for now having an openthread-specific sysroot is a great first step anyway.

This isn’t quite ready yet, though. For example, the assert macro is used heavily throughout openthread’s codebase, and right now I’m just defining it as #define assert(expr) (void)0. We’ll likely want to provide a proper assert mechanism instead—possibly with some Rust glue.

A Rust glue = extern "C" function = FFI boundary (non-inlineable) = slow. We should come up with something in pure C which is able to print the assertion issue and then reliably and cleanly panic (with e.g. *NULL = 42 or something). Perhaps the panic call could be a Rust FFI call, as at that point the assertion did fail, and we don't care about performance. Anyway, I'm sure we'll figure it out.

I’ll open a PR once I’ve had time to clean this up, but if anyone else wants to give it a go in the meantime, feel free to!

I'm swamped under my own activities, so I would patiently wait for your PR. :-)

[ivmarkov]

Though still wondering... how did you provide the C++ STL lib?

[scootermon]

Though still wondering... how did you provide the C++ STL lib?

Ran into this, but here's the neat part: I didn't! openthread doesn't actually use the STL, so I just disable them:

https://github.com/inomotech-foss/openthread/blob/556e76558d68f676d65ae8d98a1f902e75f8dcc3/openthread-sys/gen/builder.rs#L441

Their style guide reads:

The use of the C++ Standard Template Library (STL) should be avoided or minimized.