-
Notifications
You must be signed in to change notification settings - Fork 112
Description
I was trying to use embedded Rust for the first time in some real-life environment. I want to link my library written in Rust to existing C/C++ application.
It uses quite old GNU toolchain (GNU ld 2.25, dated 2015), and toolchain choice is out of my control.
So I build my library with:
- --target armv7r-none-eabi
- crate-type = ["staticlib"]
- #![no_std]
I exported one function with no_mangle and extern "C".
I got my libhello_cargo.a and told that old linker to consume it.
But it complains about EABI:
Source object libhello_cargo.a(modsi3.o) has EABI version 5, but target <my_existing_project>.o has EABI version 0
So I added --no-warn-mismatch
to see what will happen. No big surprise, it complains further about relocation size mismatch
in object files inside my library.
With some dirty hacks I'm able to link my single function (as long as it is not using floating point, to avoid linking problems with compiler builtins) to my executable and run it. But it was ugly, not acceptable - I ripped single, stripped .o file from my library and passed it to my linker.
So what I'm asking for is some way to tell Rust toolchain to generate static library suitable for linking with older EABI/toolchains.
I understand that Rust is modern tool, based on recent LLVM, etc. But here is where it meets real life legacy application and some real life ugly limitations :)
Most likely there is no simple quick answer, but I hope it will trigger some discussion what can be done about it.