Support raw-dylib link kind on ELF #135695

Noratrieb · 2025-01-18T17:33:17Z

raw-dylib is a link kind that allows rustc to link against a library without having any library files present.
This currently only exists on Windows. rustc will take all the symbols from raw-dylib link blocks and put them in an import library, where they can then be resolved by the linker.

While import libraries don't exist on ELF, it would still be convenient to have this same functionality. Not having the libraries present at build-time can be convenient for several reasons, especially cross-compilation. With raw-dylib, code linking against a library can be cross-compiled without needing to have these libraries available on the build machine. If the libc crate makes use of this, it would allow cross-compilation without having any libc available on the build machine. This is not yet possible with this implementation, at least against libc's like glibc that use symbol versioning. The raw-dylib kind could be extended with support for symbol versioning in the future.

This implementation is very experimental and I have not tested it very well. I have tested it for a toy example and the lz4-sys crate, where it was able to successfully link a binary despite not having a corresponding library at build-time.

I was inspired by Björn's comments in https://internals.rust-lang.org/t/bundle-zig-cc-in-rustup-by-default/22096/27
Tracking issue: #135694

r? bjorn3

rustbot · 2025-01-18T17:33:27Z

These commits modify compiler targets.
(See the Target Tier Policy.)

Some changes occurred in src/tools/compiletest

cc @jieyouxu

compiler/rustc_codegen_ssa/src/back/link.rs

bjorn3 · 2025-01-18T18:09:47Z

compiler/rustc_codegen_ssa/src/back/link.rs

@@ -2346,19 +2413,34 @@ fn linker_with_args(
        .native_libraries
        .iter()
        .filter_map(|(&cnum, libraries)| {
-            (dependency_linkage[cnum] != Linkage::Static).then_some(libraries)
+            if sess.target.is_like_windows {


This is fine as is for now, but once Apple targets support raw-dylib, this static deps skipping behavior should likely apply there too if you are allowed to put .tbd files in static libraries.

compiler/rustc_codegen_ssa/src/back/link.rs

compiler/rustc_target/src/spec/mod.rs

tests/ui/linkage-attr/raw-dylib/elf/basic-symbol-links-with.rs

bjorn3 · 2025-01-18T18:17:05Z

compiler/rustc_codegen_ssa/src/back/link.rs

+            let ext = if sess.target.is_like_windows {
+                if lib.verbatim { "" } else { ".dll" }
+            } else {
+                ".so"


It should be possible to handle verbatim by emitting a SONAME in the stub shared library with the actual name of the shared library and then have the stub have a name starting with lib and ending with .so like usual. We will need to support verbatim for linking against shared libraries like libc.so.6 (glibc) or basically any shared library that is part of a distro.

Do we actually need to set SONAME for verbatim? Couldn't we just name the stub library after the verbatim name and get it working directly?

No, because the linker requires the filename of every shared library to start with lib and end with .so, but with versioned shared libraries the name ends with .so.<version>. The way this normally works is by having libfoo.so.1 contains a SONAME of libfoo.so.1 and then have a symlink from libfoo.so to libfoo.so.1 in the -dev package. The linker will see libfoo.so and then encode libfoo.so.1 in the executable because of the SONAME.

I'm not sure I understand. You mentioned verbatim, but with verbatim we can just pass the -l:libfoo.so.1 to the linker and it will pick that up for the NEEDED so name. So there isn't anything we need to do to make this work. Since we do need to know the library version from the source code, verbatim is needed anyways for all these cases.

jieyouxu

compiletest changes LGTM, would be great if you could add the two new directives to the directives listing in r-d-g

compiler/rustc_target/src/spec/mod.rs

src/tools/compiletest/src/directive-list.rs

raw-dylib is a link kind that allows rustc to link against a library without having any library files present. This currently only exists on Windows. rustc will take all the symbols from raw-dylib link blocks and put them in an import library, where they can then be resolved by the linker. While import libraries don't exist on ELF, it would still be convenient to have this same functionality. Not having the libraries present at build-time can be convenient for several reasons, especially cross-compilation. With raw-dylib, code linking against a library can be cross-compiled without needing to have these libraries available on the build machine. If the libc crate makes use of this, it would allow cross-compilation without having any libc available on the build machine. This is not yet possible with this implementation, at least against libc's like glibc that use symbol versioning. The raw-dylib kind could be extended with support for symbol versioning in the future. This implementation is very experimental and I have not tested it very well. I have tested it for a toy example and the lz4-sys crate, where it was able to successfully link a binary despite not having a corresponding library at build-time.

rustbot · 2025-01-19T10:45:08Z

The rustc-dev-guide subtree was changed. If this PR only touches the dev guide consider submitting a PR directly to rust-lang/rustc-dev-guide otherwise thank you for updating the dev guide with your changes.

cc @BoxyUwU, @jieyouxu, @Kobzol

rustbot assigned bjorn3 Jan 18, 2025

Noratrieb mentioned this pull request Jan 18, 2025

Tracking Issue for raw-dylib on ELF #135694

Open

5 tasks

This comment has been minimized.

Sign in to view