Change:
))?; // if `dir` points target's dir, move up to the sysroot <del> if dir.ends_with(crate::config::host_triple()) { </del> <ins> let mut sysroot_dir = if dir.ends_with(crate::config::host_triple()) { </ins> dir.parent() // chop off `$target` .and_then(|p| p.parent()) // chop off `rustlib` <del> .and_then(|p| { // chop off `lib` (this could be also $arch dir if the host sysroot uses a // multi-arch layout like Debian or Ubuntu) match p.parent() { Some(p) => match p.file_name() { Some(f) if f == "lib" => p.parent(), // first chop went for $arch, so chop again for `lib` _ => Some(p), }, None => None, } }) </del> <ins> .and_then(|p| p.parent()) // chop off `lib` </ins> .map(|s| s.to_owned()) <del> .ok_or(format!( "Could not move 3 levels upper using `parent()` on {}", dir.display() )) </del> <ins> .ok_or_else(|| { format!("Could not move 3 levels upper using `parent()` on {}", dir.display()) })? </ins> } else { <del> Ok(dir.to_owned()) </del> <ins> dir.to_owned() }; // On multiarch linux systems, there will be multiarch directory named // with the architecture(e.g `x86_64-linux-gnu`) under the `lib` directory. // Which cause us to mistakenly end up in the lib directory instead of the sysroot directory. if sysroot_dir.ends_with("lib") { sysroot_dir = sysroot_dir.parent().map(|real_sysroot| real_sysroot.to_owned()).ok_or_else( || format!("Could not move to parent path of {}", sysroot_dir.display()), )? </ins> } <ins> Ok(sysroot_dir) </ins> } // Use env::args().next() to get the path of the executable without

Discussion:
<!-- Thank you for filing a regression report! A regression is something that changed between versions of Rust but was not supposed to. Please provide a short summary of the regression, along with any information you feel is relevant to replicate it. --Debian deploys a multiarch schema. For Rust, and other shared libraries needed for to run are installed to on x8664. And directory is installed as . During Rust build, Debian just lets install the shared libraries to , and then manually moves them to . This works before 1.67. But since 1.67, will fail to find crate, since tries to find directory through a relative path based on . guesses directory is aka , which does not exist. To work around this, Ubuntu deploys a downstream . But as with that patch actually breaks what Rust 1.67 trying to get. I hope Rust upstream can provide a better solution for this installation schema to work without downstream patch. <!-- Provide the most recent version this worked on, for example: It most recently worked on: Rust 1.47 --It most recently worked on: Rust 1.66.1 67
Additional context from the linked u.r.l.o forum: and cc:
Thank you for the report. I can take care of it over the weekend. If anyone has time, feel free taking/fixing this before the weekend.
Just remember we have already patched sys detection for supporting multiarch systems. Related commit It's to milestone.
Oh! The same author of the Ubuntu patch.
Hi, I'm experiencing the same issue when packaging 1.67 for Debian. as mentioned by didn't work. The fix is behind a check , which evaluates to false because is on x8664 and is , where Debian installs multi-arch libs for x8664. I'm testing with a clause that simply checks against , but open to better solutions.
How did you test that patch? It's not shipped with
The fix isn't shipped with 1.67, but the problematic code it's for is. I was building 1.68 with this 1.67, met this issue, cherry picked this fix, still met this issue, and figured the check evaluates to false, causing the fix to not take effect.
Thank you for your feedback, I will check it this week.

A deeper look concluded my previous finding partially wrong. In , before the aforementioned check, two levels are unconditionally chopped off from the path of . On Debian it's currently installed to , so after that becomes . The check will, of course, evaluate to false, because there's no more arch specific directory on the path. The comment line " will be in one of the following two" may need to be changed to three. Update_: A test that special-case's Debian's situation worked, see
I have tested on Debian 11, worked just fine. It's under review progress now.
I see, thanks for the help I'll cherry-pick that then.