Support a mixture of dynamic and shared rust libraries when linking #10729
Comments
alexcrichton
added a commit
to alexcrichton/rust
that referenced
this issue
May 2, 2014
Currently, rustc requires that a linkage be a product of 100% rlibs or 100% dylibs. This is to satisfy the requirement that each object appear at most once in the final output products. This is a bit limiting, and the upcoming libcore library cannot exist as a dylib, so these rules must change. The goal of this commit is to enable *some* use cases for mixing rlibs and dylibs, primarily libcore's use case. It is not targeted at allowing an exhaustive number of linkage flavors. There is a new dependency_format module in rustc which calculates what format each upstream library should be linked as in each output type of the current unit of compilation. The module itself contains many gory details about what's going on here. cc rust-lang#10729
bors
added a commit
that referenced
this issue
May 7, 2014
Currently, rustc requires that a linkage be a product of 100% rlibs or 100% dylibs. This is to satisfy the requirement that each object appear at most once in the final output products. This is a bit limiting, and the upcoming libcore library cannot exist as a dylib, so these rules must change. The goal of this commit is to enable *some* use cases for mixing rlibs and dylibs, primarily libcore's use case. It is not targeted at allowing an exhaustive number of linkage flavors. There is a new dependency_format module in rustc which calculates what format each upstream library should be linked as in each output type of the current unit of compilation. The module itself contains many gory details about what's going on here. cc #10729
|
Closing, this was predominately done in #13892 and we can continue to refine it over time. |
flip1995
pushed a commit
to flip1995/rust
that referenced
this issue
Jun 30, 2023
[`option_if_let_else`]: suggest `.as_ref()` if scrutinee is of type `&Option<_>` Fixes rust-lang#10729 `Option::map_or` takes ownership, so if matching on an `&Option<_>`, we need to suggest `.as_ref()` before calling `map_or` to get the same effect and to not cause a borrowck error. changelog: [`option_if_let_else`]: suggest `.as_ref()`/`.as_mut()` if scrutinee is of type `&Option<_>`/`&mut Option<_>`
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Once #10528 lands, we will have added static linking to rust. The caveat is that linking requires everything to be static or everything to be dynamic. This is not ideal, because one can easily think of cases where a dynamic library has static rust dependencies.
The major problem when doing this is to ensure that only one copy of a library shows up in the final result. For example, you can't statically link libstd to a dynamic library and then also statically link it into an executable.
This would probably involve encoding into the metadata what rust libraries were used, but this is not an easy change right now. The metadata is encoded into the object file that LLVM produces, and we use that same object file to produce the outputs desired by the compilation (you can simultaneously output an rlib and a dylib without having to recompile). Perhaps this is another case for separate metadata files? (libfoo.rlib.metadata and libfoo.dylib.metadata or something like that).
Regardless, the compiler should emit an error when it detects two versions of a rust library being available in the final executable, and it should also make it difficult for that to happen. This will likely involve altering how you declare dependencies to rust libraries.
The main use case that I have in mind is that a rust build dependency of a dynamic library should not need to get distributed. For this, perhaps the dynamic library declares its dependency on the rust build dependency declaring that it must statically link to that, but dynamic linking still favors linking to libstd dynamically (just as an example).
Regardless, this type of mixing of libraries should be possible in one form or another, and this probably means giving crates fine-grained controls over whether their dependencies are dynamic or static and then having reasonable defaults (and all of this is coupled with error messages on behalf of the compiler).
The text was updated successfully, but these errors were encountered: