`dylib` shared libraries will not make public symbols that may be necessary to link inlined code

[nagisa]

When a dylib crate has a public inline(always) functions in it that use, as an implementation, other, private functions, using these public functions from other crates will fail with linkage errors because we fail to "export" the private functions.

An example project can be seen here. In this example the driver dylib crate privately externs a symbol from a static C library and uses it to implement an inline(always) interface/wrapper. The user crate then attempts to use the inline(always) wrapper, but linking fails with an error such as this:

/tmp/user/driver/src/lib.rs:8: undefined reference to `private_extern_symbol'

When inspecting the libdriver.so we can see that the extern symbol does indeed exist but is "private":

0000000000001100 t private_extern_symbol

I think we might be un-exporting items too aggressively here. cc @michaelwoerister @oli-obk

Blocks #55617

Regression from 1.36.0 (example builds successfully) to 1.37 (example fails to build).

[michaelwoerister]

Yeah, I can imagine that that doesn't work. Maybe #59752 is related?

[nagisa]

Did a rustc bisect and it is indeed dbebcee (#59752)

[nagisa]

cc @Zoxc

[Zoxc]

You haven't told rustc where that symbol comes from. Try adding #[link(name = "foo", kind = "static")] on the extern block.

[nagisa]

Adding the attribute helped, however these symbols are originally linked via command line arguments that cc crate emits to cargo from the build.rs script. Why the two ways to link in stuff have different behaviour?

[Zoxc]

When you link the library on the command line, rustc doesn't know which symbols are in it, so it won't export any.

[nagisa]

Okay, that’s somewhat bad, then, because libraries that rely exclusively on arguments emitted by cc for linking purposes are very abound in the ecosystem.

We should look at updating the cc’s documentation to include information about needing the #[link] attribute regardless. cc @alexcrichton

[Zoxc]

We could perhaps just consider all reachable extern fns to have static linkage and export them. I'm not sure if there's any problems with that though...

[alexcrichton]

I don't think you need the kind on the block since the kind is specified on the command line and that overrides what the block says, but yes adding this documentation to cc seems fine.