Add rule for `crate_type = dylib`

[UebelAndre]

We have rust_shared_library which is cdylib but we have no rules for dylib (forum), should this be introduced?

[UebelAndre]

cc @krasimirgg @slackito

[krasimirgg]

Just thinking out loud, compared to c++, I think crate_type = dylib doesn't correspond to a separate rule type, but to something that's produced by rust_library itself depending on the bazel --dynamic_mode knobs. I say compared to C++, where cc_library actions generate actions for both static and dynamic library outputs, and binaries choose the appropriate flavor based on the dynamic mode chosen

[UebelAndre]

The desire isn't to globally affect the behavior, it's to take some large dependencies that are expensive to link and convert the to a dynamic library and have them loaded at runtime so it would seem --dynamic_mode is maybe orthogonal? My thought was maybe introducing rust_cdylib_library which rust_shared_library becomes an alias for, and then a rust_dylib_library which is more akin to a rust_library but outputs a .so/.dll vs .rlib and is linked appropriately. But I'm interested in other options.

[krasimirgg]

I think the problem is that effectively the build graph and rustc invocations force something akin to a global behavior... (I'm not a dynamic linking expert)
In a build graph, any (transitive) .rlib dependency of a rust_dylib_library risks being linked into the .so; so any client to the rust_dylib_library risks getting duplicate symbol/crate errors due to common dependencies of the client itself and the rust_dylib_library. For example, if I read the idea correctly, if you have:

rust_library(name = "d")
rust_dylib_library(name = "c", deps = ["d"])
rust_dylib_library(name = "b", deps = ["d"])
rust_library(name = "a", deps = ["c", "b"])

, you'll likely get rustc error: cannot satisfy dependencies so d only shows up once while compiling a. Example rustc commands I'm thinking about -- https://gist.github.com/krasimirgg/66c52fbebee7af4813e1e71af495bd4a.

Effectively, dependencies or dylib-s need themselves to be turned into dylibs in general to allow rustc to de-duplicate them while compiling arbitrary transitive clients.

(and that's where dynamic-mode could come in -- rust_library potentially creates both an .rlib and an .so; and clients trigger the action that creates the appropriate one based on the global dynamic-mode preference).

[UebelAndre]

#4179 relates to this