Large rlib unable to be loaded #88351
Comments
|
I’ve encountered this issue when building rustc with LLVM debug symbols enabled, since that creates a very large The error message should be improved as well, because the only way to know what’s happening is to turn on rustc logging. This is also a regression from Rust 1.54 since the |
jonas-schievink
added
A-metadata
rustbot
added
the
I-prioritize
jonas-schievink
added
regression-from-stable-to-beta
|
Progress is being made on this, will likely need a bump to the object crate (and backported) once that's released, cc gimli-rs/object#365 |
I originally intended the |
|
Published |
|
Working on a patch bumping object, going to try and make the test @ehuss suggested into a run-make test as well. |
Fix loading large rlibs Bumps object crate to permit parsing archives with 64-bit table entries. These are primarily encountered when there's more than 4GB of archive data. cc gimli-rs/object#365 Helps with rust-lang#88351, but will also need a beta backport r? `@ehuss` (mostly for the test)
|
Assigning priority as discussed in the Zulip thread of the Prioritization Working Group. @rustbot label -I-prioritize +P-medium |
rustbot
added
P-medium
…ulacrum [beta] backports This PR backports: * Concrete regions can show up in mir borrowck if the originated from there rust-lang#88533 (fixes rust-lang#83190) * Fix loading large rlibs rust-lang#88506 (fixes rust-lang#88351) * Display associated types of implementors rust-lang#88490 (fixes rust-lang#86631) * Tracking issue for UNSUPPORTED_CALLING_CONVENTIONS rust-lang#88397 r? `@Mark-Simulacrum`
|
@Mark-Simulacrum Can this be closed now? |
|
Huh, yes. I thought I had marked the backport rollup as "fixes" for this issue (and some others), but that seems to have not worked. |
|
Ah, yea, the "fixes" keywords only work on the default branch (master). |
A user reported a strange error here when using
llvm-syswhererustcreports the cryptic error:After some digging, the error seems to be the crate reader is unable to read the rlib:
The user shared the rlib file, and it was over 4GB in size. Some further investigation shows that LLVM creates large archives with a
/SYM64/symbol table instead of the more common/.This is actually an issue with the
objectcrate, and I have filed gimli-rs/object#365 with more details there. However, I'm also filing it here since this relates to rustc/LLVM creating an rlib that rustc cannot read.Here is a reproducer. This may take a few minutes to run, and requires several GB of disk space. There is probably an easier way to reproduce, but this was an easy hack. This needs to be run on a Linux system. The final step of building
bar.rsshould fail witherror[E0463]: can't find crate for `foo`.Meta
rustc --version --verbose:Here are the contents of the original libllvm_sys rlib file:
libllvm_sys.rlib
The text was updated successfully, but these errors were encountered: