Inconsistent linking against stdlib based on whether a Workspace is used

[illicitonion]

Minimal repro: https://github.com/illicitonion/repro-rustworkspacerpath

I have a dynamic library which I produce. I am trying to split it into a few crates internally, to logically decompose it, and speed up compilation. I would like to end up producing a dylib with no runtime dependencies on the system (as I do when just building one crate).

If I decompose into sub-crates and don't add a [workspace] section to my Cargo.toml, my top-level dylib is produced as I expect. It has no dynamic dependency on libstd listed when I run otool -L on my Mac. However, cargo test --all doesn't pick up the sub-crate tests.

If I add a [workspace] section to my Cargo.toml, cargo test --all picks up the sub-crate tests, but my top-level dylib now has a dynamic dependency on libstd.

As far as I can tell, there doesn't appear to be a way to both have --all work, and not pick up a runtime dependency on a dylib which I'd like to avoid.

Which of the following is the bug, I'm not sure:

1. cargo test --all doesn't pick up non-workspace sub-crates
2. cargo build produces different linkage configuration depending on whether you're in a workspace
   but it seems wrong that there's no way to get the best of both behaviours.

[retep998]

I would like to end up producing a dylib with no runtime dependencies on the system

Are you trying to create a dylib that can be consumed by other languages? If so, you want cdylib, not dylib.

[illicitonion]

That is what I'm trying to do, specifically for use by Python.

I have a rust library which also uses some C code, and I need to export both rust and C functions to the calling language (Python).

I tried switching to a cdylib, and this appears to end up stripping my C functions out of the produced cdylib. As far as I can tell from https://github.com/rust-lang/rust/issues/36342 and https://users.rust-lang.org/t/re-export-c-functions/7219/2 there isn't a way to explicitly re-export C functions. I tried disabling LTO, and still found my C functions weren't present in the linked cdylib.

So, from what I can tell, the only way I can end currently up with a non-stripped dylib, and parallelise and minimise my incremental compilation, is to compile a dylib (not cdylib), with no [workspace] declaration. Which works for everything (though perhaps accidentally, rather than intentionally), except for breaking cargo's --all functionality.

I guess the desired end-state is that there's a way to re-export C functions, and that I use a cdylib with re-exported C functions as-per https://github.com/rust-lang/rust/issues/36342, but that seems like it may be a ways off...

[retep998]

I guess the desired end-state is that there's a way to re-export C functions, and that I use a cdylib with re-exported C functions as-per #36342, but that seems like it may be a ways off...

That is the desired end-state. Sorry that re-exporting C functions isn't working yet.