-
Notifications
You must be signed in to change notification settings - Fork 169
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[WIP] Support building against c libraries with libc or newlib / nosys #255
Comments
Hey, curious to know if you found solutions to this issue ? I'm facing a similar problem, I thought i had fixed it but my device is now hardfaulting |
I successfully linked newlib symbols in https://github.com/gmmyung/eerie/blob/0.2.0/eerie-sys/build.rs. I am just not sure if this is safe in embedded frameworks such as embassy or rtic, since I thought nosys newlib assumes single thread execution flow. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Not sure if this is a candidate for the rust-and-c section or if it's too cursed and should go in the `nomicon. Fair warning this is also a bit ranty and all over the show (sorry), and I haven't succeeded at this yet so, any guidance / advice / improvement is greatly appreciated, just want it posted somewhere on the internet so noone else has to got at it alone.
When linking against existing c libraries you may need symbols from 'libc' and/or libnosys. Unfortunately for us, rust's libc elects not to provide any bindings for non-standard targets. cty can be used in place of
libc
for primitive type definitions, but if you need the classic posixlibc
functions you're right outa luck.You'll know if this is required because linking will fail with a bunch of undefined symbols for
libc
components like:or for
newlib
components like:The compiler builtins way
Using Rust-lang/compiler-builtins, which should work for most cases, unless the library you're building requires
--specs=nosys.spec
, in which case it might not or I might be missing something.First add the dependency:
Make sure it's used:
Get yourself a copy of
compiler-rt
:TODO: work out how to do this?? (see: rust-lang/compiler-builtins#363)
Profit?
The libc way
To deal with this this the libc way, you need to add libc via either:
Adding a link attribute to your
main.rs
forlibc
and (optionally) `libnosys:Or, adding a linker argument to your
.cargo/config
for the required target.Unfortunately cargo does not seem to pass enough information for the linker to determine which ABI you are using and provide the correct library path, which results in a lot of linker errors along the lines of
Failed to merge target specific data of file X, error: X uses VFP register arguments but Y does not
, unsure if this is an oversight or intended, but it results in:To mitigate this, add yet another linker argument (with the correct architecture and floating point kind) so the linker can find the correct library version...
Once you've got libc linking you have a couple of options for resolving the required stubs.
Defining the stubs in rust
If you don't care about the libc calls, or are willing to implement the libc stubs as required, you can define these in your rust app.
TODO: wouldn't it be great if we had a
libnosys
package that defined these in a rust-compatible manner?Using
libnosys
If you don't want to implement the stubs yourself, you can link
libnosys
using either of the earlier methods. Note that this will result in two parallel methods for doing things like, allocation, and you'll need to work out how to setup anend
symbol to help with memory allocation/deallocation to resolve the following:TODO: work out how to add this without it being, terrible. May be able to use daniel5151/libc_alloc on the rust side to avoid terrible conflicting allocator situations? idk.
Related issues / posts / eulogies:
no_std
which was the cause of this (mis)adventure sodiumoxide#363The text was updated successfully, but these errors were encountered: