Support raw-dylib link kind on ELF #135695
Open
+829
−213
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
|
These commits modify compiler targets. Some changes occurred in src/tools/compiletest cc @jieyouxu |
5 tasks
This comment has been minimized.
This comment has been minimized.
bjorn3
reviewed
Jan 18, 2025
bjorn3
reviewed
Jan 18, 2025
bjorn3
reviewed
Jan 18, 2025
bjorn3
reviewed
Jan 18, 2025
bjorn3
reviewed
Jan 18, 2025
bjorn3
reviewed
Jan 18, 2025
bjorn3
reviewed
Jan 18, 2025
bjorn3
reviewed
Jan 18, 2025
b057efd to
35d33ec
Compare
This comment has been minimized.
This comment has been minimized.
7b85a6a to
f339acd
Compare
This comment was marked as outdated.
This comment was marked as outdated.
This comment has been minimized.
This comment has been minimized.
f339acd to
be04b07
Compare
This comment has been minimized.
This comment has been minimized.
jieyouxu
approved these changes
Jan 19, 2025
be04b07 to
fdd5c1c
Compare
fdd5c1c to
233d6c2
Compare
eec2be6 to
7ff0d14
Compare
This comment has been minimized.
This comment has been minimized.
7ff0d14 to
84d588f
Compare
This comment has been minimized.
This comment has been minimized.
84d588f to
e03e2b1
Compare
bjorn3
reviewed
Feb 2, 2025
e03e2b1 to
acf5f79
Compare
bjorn3
approved these changes
Feb 2, 2025
acf5f79 to
f62d1ed
Compare
|
@bors r=bjorn3 |
matthiaskrgr
added a commit
to matthiaskrgr/rust
that referenced
this pull request
Feb 3, 2025
Support raw-dylib link kind on ELF 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: rust-lang#135694 r? bjorn3
bors
added a commit
to rust-lang-ci/rust
that referenced
this pull request
Feb 3, 2025
…iaskrgr Rollup of 8 pull requests Successful merges: - rust-lang#134777 (Enable more tests on Windows) - rust-lang#134807 (fix(rustdoc): always use a channel when linking to doc.rust-lang.org) - rust-lang#135621 (Move some std tests to integration tests) - rust-lang#135695 (Support raw-dylib link kind on ELF) - rust-lang#135836 (bootstrap: only build `crt{begin,end}.o` when compiling to MUSL) - rust-lang#136235 (Pretty print pattern type values with transmute if they don't satisfy their pattern) - rust-lang#136392 (bootstrap: add wrapper macros for `feature = "tracing"`-gated `tracing` macros) - rust-lang#136462 (mir_build: Simplify `lower_pattern_range_endpoint`) r? `@ghost` `@rustbot` modify labels: rollup
raoulstrackx
reviewed
Feb 3, 2025
| @@ -0,0 +1,15 @@ | |||
| //@ only-elf | |||
There was a problem hiding this comment.
The x86_64-fortanix-unknown-sgx target doesn't support dynamic linking. Can you please add //@ ignore-sgx to ignore this platform?
There was a problem hiding this comment.
Would //@ needs-dynamic-linking work too?
There was a problem hiding this comment.
Yes, I will add that directive, I won't add any target specific directive for no reason. @raoulstrackx please don't suggest ignoring SGX directly in the future, instead suggest using directives like needs-dynamic-linking or similar to achieve what we need.
There was a problem hiding this comment.
Oh I didn't know about the needs-dynamic-linking directive. Good to know!
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.
f62d1ed to
9527c48
Compare
|
@bors try |
bors
added a commit
to rust-lang-ci/rust
that referenced
this pull request
Feb 3, 2025
Support raw-dylib link kind on ELF 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: rust-lang#135694 r? bjorn3 try-job: aarch64-apple try-job: x86_64-msvc-1 try-job: x86_64-msvc-2
|
The job Click to see the possible cause of the failure (guessed by this bot) |
|
The job Click to see the possible cause of the failure (guessed by this bot) |
|
💔 Test failed - checks-actions |
|
☔ The latest upstream changes (presumably #136684) made this pull request unmergeable. Please resolve the merge conflicts. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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
try-job: aarch64-apple
try-job: x86_64-msvc-1
try-job: x86_64-msvc-2