Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Unify dylib loading between proc macros and codegen backends #121392

Merged
merged 1 commit into from
Feb 22, 2024

Conversation

bjorn3
Copy link
Member

@bjorn3 bjorn3 commented Feb 21, 2024

As bonus this makes the errors when failing to load a proc macro more informative to match the backend loading errors. In addition it makes it slightly easier to patch rustc to work on platforms that don't support dynamic linking like wasm.

As bonus this makes the errors when failing to load a proc macro more
informative to match the backend loading errors. In addition it makes it
slightly easier to patch rustc to work on platforms that don't support
dynamic linking like wasm.
@rustbot
Copy link
Collaborator

rustbot commented Feb 21, 2024

r? @petrochenkov

rustbot has assigned @petrochenkov.
They will have a look at your PR within the next two weeks and either review your PR or reassign to another reviewer.

Use r? to explicitly pick a reviewer

@rustbot rustbot added S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. labels Feb 21, 2024
@rustbot
Copy link
Collaborator

rustbot commented Feb 21, 2024

These commits modify the Cargo.lock file. Unintentional changes to Cargo.lock can be introduced when switching branches and rebasing PRs.

If this was unintentional then you should revert the changes before this PR is merged.
Otherwise, you can ignore this comment.

@petrochenkov
Copy link
Contributor

@bors r+

@bors
Copy link
Contributor

bors commented Feb 21, 2024

📌 Commit f25c90a has been approved by petrochenkov

It is now in the queue for this repository.

@bors bors added S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Feb 21, 2024
bors added a commit to rust-lang-ci/rust that referenced this pull request Feb 22, 2024
…iaskrgr

Rollup of 8 pull requests

Successful merges:

 - rust-lang#121206 (Top level error handling)
 - rust-lang#121261 (coverage: Remove `pending_dups` from the span refiner)
 - rust-lang#121336 (triagebot: add queue notifications)
 - rust-lang#121373 (Consistently refer to a test's `revision` instead of `cfg`)
 - rust-lang#121391 (never patterns: Fix liveness analysis in the presence of never patterns)
 - rust-lang#121392 (Unify dylib loading between proc macros and codegen backends)
 - rust-lang#121399 (Solaris linker does not support --strip-debug)
 - rust-lang#121406 (Add a couple tests)

r? `@ghost`
`@rustbot` modify labels: rollup
@bors bors merged commit 64dbc3f into rust-lang:master Feb 22, 2024
11 checks passed
@rustbot rustbot added this to the 1.78.0 milestone Feb 22, 2024
rust-timer added a commit to rust-lang-ci/rust that referenced this pull request Feb 22, 2024
Rollup merge of rust-lang#121392 - bjorn3:unify_dylib_loading, r=petrochenkov

Unify dylib loading between proc macros and codegen backends

As bonus this makes the errors when failing to load a proc macro more informative to match the backend loading errors. In addition it makes it slightly easier to patch rustc to work on platforms that don't support dynamic linking like wasm.
@bjorn3 bjorn3 deleted the unify_dylib_loading branch February 22, 2024 10:58
GuillaumeGomez added a commit to GuillaumeGomez/rust that referenced this pull request Mar 4, 2024
…th, r=bjorn3

Fix duplicated path in the "not found dylib" error

While working on the gcc backend, I couldn't figure out why I had this error:

```
error: couldn't load codegen backend /checkout/compiler/rustc_codegen_gcc/target/release/librustc_codegen_gcc.so/checkout/compiler/rustc_codegen_gcc/target/release/librustc_codegen_gcc.so: cannot open shared object file: No such file or directory
```

As you can see, the path is duplicated for some reason. After investigating a bit more, I realized that `libloading::Error::LoadLibraryExW` starts with the path of the not found dylib, making it appear twice in our error afterward (because we do render it like this: `{path}{err}`, and since the `err` starts with the path...).

Thanks to `@bjorn3` for linking me to rust-lang#121392. :)
jhpratt added a commit to jhpratt/rust that referenced this pull request Mar 5, 2024
…th, r=bjorn3

Fix duplicated path in the "not found dylib" error

While working on the gcc backend, I couldn't figure out why I had this error:

```
error: couldn't load codegen backend /checkout/compiler/rustc_codegen_gcc/target/release/librustc_codegen_gcc.so/checkout/compiler/rustc_codegen_gcc/target/release/librustc_codegen_gcc.so: cannot open shared object file: No such file or directory
```

As you can see, the path is duplicated for some reason. After investigating a bit more, I realized that `libloading::Error::LoadLibraryExW` starts with the path of the not found dylib, making it appear twice in our error afterward (because we do render it like this: `{path}{err}`, and since the `err` starts with the path...).

Thanks to ``@bjorn3`` for linking me to rust-lang#121392. :)
matthiaskrgr added a commit to matthiaskrgr/rust that referenced this pull request Mar 5, 2024
…th, r=bjorn3

Fix duplicated path in the "not found dylib" error

While working on the gcc backend, I couldn't figure out why I had this error:

```
error: couldn't load codegen backend /checkout/compiler/rustc_codegen_gcc/target/release/librustc_codegen_gcc.so/checkout/compiler/rustc_codegen_gcc/target/release/librustc_codegen_gcc.so: cannot open shared object file: No such file or directory
```

As you can see, the path is duplicated for some reason. After investigating a bit more, I realized that `libloading::Error::LoadLibraryExW` starts with the path of the not found dylib, making it appear twice in our error afterward (because we do render it like this: `{path}{err}`, and since the `err` starts with the path...).

Thanks to ```@bjorn3``` for linking me to rust-lang#121392. :)
matthiaskrgr added a commit to matthiaskrgr/rust that referenced this pull request Mar 5, 2024
…th, r=bjorn3

Fix duplicated path in the "not found dylib" error

While working on the gcc backend, I couldn't figure out why I had this error:

```
error: couldn't load codegen backend /checkout/compiler/rustc_codegen_gcc/target/release/librustc_codegen_gcc.so/checkout/compiler/rustc_codegen_gcc/target/release/librustc_codegen_gcc.so: cannot open shared object file: No such file or directory
```

As you can see, the path is duplicated for some reason. After investigating a bit more, I realized that `libloading::Error::LoadLibraryExW` starts with the path of the not found dylib, making it appear twice in our error afterward (because we do render it like this: `{path}{err}`, and since the `err` starts with the path...).

Thanks to ````@bjorn3```` for linking me to rust-lang#121392. :)
matthiaskrgr added a commit to matthiaskrgr/rust that referenced this pull request Mar 5, 2024
…th, r=bjorn3

Fix duplicated path in the "not found dylib" error

While working on the gcc backend, I couldn't figure out why I had this error:

```
error: couldn't load codegen backend /checkout/compiler/rustc_codegen_gcc/target/release/librustc_codegen_gcc.so/checkout/compiler/rustc_codegen_gcc/target/release/librustc_codegen_gcc.so: cannot open shared object file: No such file or directory
```

As you can see, the path is duplicated for some reason. After investigating a bit more, I realized that `libloading::Error::LoadLibraryExW` starts with the path of the not found dylib, making it appear twice in our error afterward (because we do render it like this: `{path}{err}`, and since the `err` starts with the path...).

Thanks to `````@bjorn3````` for linking me to rust-lang#121392. :)
rust-timer added a commit to rust-lang-ci/rust that referenced this pull request Mar 6, 2024
Rollup merge of rust-lang#121978 - GuillaumeGomez:dylib-duplicated-path, r=bjorn3

Fix duplicated path in the "not found dylib" error

While working on the gcc backend, I couldn't figure out why I had this error:

```
error: couldn't load codegen backend /checkout/compiler/rustc_codegen_gcc/target/release/librustc_codegen_gcc.so/checkout/compiler/rustc_codegen_gcc/target/release/librustc_codegen_gcc.so: cannot open shared object file: No such file or directory
```

As you can see, the path is duplicated for some reason. After investigating a bit more, I realized that `libloading::Error::LoadLibraryExW` starts with the path of the not found dylib, making it appear twice in our error afterward (because we do render it like this: `{path}{err}`, and since the `err` starts with the path...).

Thanks to `````@bjorn3````` for linking me to rust-lang#121392. :)
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants