My requirement I will build a .so library from utils in a separate directory and main from another directory the main should only have the so it can't have the source code, if needed you can use any intermediate in between for function symbols but strictly no cdylib and extern c no FFI
just utils build separately and main built using the utils output so only or any supporting file but not source code
If you want to link against another library then you need some stable way to call into it.
The lowest common denominator for that is the C FFI.
The Rust ABI is not stable, so you can't rely on being able to call it across the shared library boundary.
There's many ways to hide most of the underlying C FFI part, e.g. abi_stable.
I believe Stabby — C interface for Rust // Lib.rs sees more active development than abi_stable at this point, but I have yet to use either. In fact abi_stable hasn't had a commit since 2023
what if
I have stable rust toolchain config
[toolchain]
channel = "1.93.0"
targets = ["x86_64-unknown-linux-gnu"]
components = ["rustfmt", "clippy"]
I will have an so
[target.x86_64-unknown-linux-gnu]
rustflags = [
"-C","prefer-dynamic",
"-L", "libs",
]
the config also will have these
and I will build so independently but the same tool chain, i will build the main modules independently using the library utils and also the same toolchain
Consider using markdown syntax so your code blocks are readable:
```toml
Toml code here
```
But I don't understand your goal here. Rust doesn't have a stable ABI, not even between builds on the same version but different build trees. That makes this type of dynamic linking largely useless, except for saving on rebuild and link time when working incrementally on a feature.
Rust also inlines code heavily between crates, which is also needed as soon as you have generics. The needed data for that is in the rmeta files as I understand it, which isn't portavle between rust versions either.
But that isn't all, if a crate is used both via the dylib and from the application those must be unified. This includes std which everyone likely depends on. Since std doesn't have feature flags this isn't too bad, but any other dependency you would have to exactly match feature flags between the dylib and the consumer of the dylib.
The better option is to expose a C ABI, or use something like stabby. Or just distribute the source to the consumer. They would probably appreciate having that anyway, at my dayjob we have a policy that we are not buying any third party library unless we get the code (possibly under NDA). Not having the code makes debugging too painful, and means you are no longer in control of your own product.
If that's an actual requirement then it's time to start doing fork of Rust compiler because what you describe is explicit “non-goal” for the Rust team.
But maybe your actual requirements are different? Then things may still work.
Then it will break, sooner or later — and then you would hold all the pieces. You may start your journey at special, alternate, Rust compiler from there.
It's not that what you describe is impossible, it's simply “non-goal”: something that Rust team explicitly doesn't want to support. It doesn't mean it's literally impossible, it just means that someone else have to support it.