cargo-c generated libraries also export all extern nomangle symbols irrespective of crate

[amyspark]

Hi @lu-zero ,

This is to let you know that shared libraries generated by cargo-c, at least on Windows, also suffer from the issue described in rust-lang/rust#73958. All extern nomangle symbols, irrespective of whether they reside on the topmost crate or any dependency, are exported by the DLL.

The only way to work around this has been to use cargo-c to generate a static library only, and then manually link it with /WHOLEARCHIVE along with a list of exportable symbols. This also means that the pkg-config module needs to be generated externally, as the cargo-c version will output a lot of unnecessary libraries. (Also a tool like Meson is unable to read it at build time.)

This is how I achieved it in librsvg: https://github.com/GNOME/librsvg/blob/2b122dca23abb95dd61870104df06512d6d6ca06/rsvg/meson.build#L104-L213

[lu-zero]

Do you have plans to fix the root problems in cargo/rustc? I'm not sure there is a good way to address it in cargo-c itself.

[amyspark]

@lu-zero No(t yet), unfortunately I'm not familiar with rustc or Cargo development.