cargo doesn't transiently pass undefined symbols

[DrewRidley]

Hey all,

I am compiling a fairly complex library from C# with NativeAOT into a statically linked binary. NativeAOT requires that at link time, a specific argument is included _NativeAOT_StaticInitialization. If I write a FFI crate to interop with this library, and add:
println!("cargo:rustc-link-args=-Wl,-u,_NativeAOT_StaticInitialization");
It seems to work at first glance. I wrote some unit tests to verify this behavior, and the unit tests pass. The undefined symbol is correctly included in the final binary and the NativeAOT code runs as expected.

Unfortunately, this behavior is not consistent when the same exact unit test is copied into a dependent crate. Adding the original FFI crate as a dependency seems to cause a segmentation fault which is due to the undefined symbol no longer existing in the binary.

I am not entirely sure how I can help, if it would be of assistance I can provide the specific statically linked library in question for reproduction? I suspect what happens is that when rust compiles the internal unit test, it directly links against the static lib into a binary without an intermediate rlib.

I was hoping someone could point me in the right direction towards a specific flag I can use here, or another tracking issue for a similar issue?

Any help or guidance on this matter would be much appreciated.
Thanks

[workingjubilee]

I thought the Cargo command is rustc-link-arg, not rustc-link-args? Do both work? That's interesting.

Nonetheless, your problem is not exactly a rustc one, it is a cargo one: rustc is not responsible for how cargo drives it, and while it does invoke a compiler for performing linkage, build.rs is a cargo feature, as is essentially everything concerning the multiple-crate ecosystem. But I believe the hesitation in passing things along is deliberate:

• rustc-link-arg does not propagate transitively cargo#9554

Based on scanning that thread, it seems the intent is that you should define a way for dependents to deliberately opt-in, rather than allowing you to muck up the linkage of other crates at will.

[DrewRidley]

Thanks for getting back to me. This is definitely no fault of rust and its a rather peculiar situation, whereby microsoft decided to mandate that consumers of their static libraries produced through NativeAOT have a forced, undefined symbol to initialize statically.

For some reason, println!("cargo:rustc-link-args=-Wl,-u,_NativeAOT_StaticInitialization"); works for the local unit test in the FFI crate, but when copied over to the dependent library like described, it still falls flag. Removing the the s and making it link-arg seemed to fix the issue.

Not really sure why there would be any different between the two only in the dependent crate?
Regardless I now know the solution. Thank you for your help

[workingjubilee]

Mildly vexing but not too surprising! Closing this as there is effectively "nothing to do" here, if a further request is desired a new issue can be opened at rust-lang/cargo's issue tracker.