Manually moving shared libraries to a multiarch libdir, eg, /usr/lib/x86_64-linux-gnu, breaks after 1.67

[cheese]

Description

Debian deploys a multiarch schema. For Rust, librustc_driver-*.so and other shared libraries needed for rustc to run are installed to /usr/lib/x86_64-linux-gnu on x86_64. And rustlib directory is installed as /usr/lib/rustlib.

During Rust build, Debian just lets x.py install the shared libraries to /usr/lib, and then manually moves them to /usr/lib/x86_64-linux-gnu.

This works before 1.67.

But since 1.67, rustc will fail to find std crate, since rustc tries to find rustlib directory through a relative path based on librustc_driver-*.so. rustc guesses rustlib directory is /usr/lib/x86_64-linux-gnu/../lib/rustlib aka /usr/lib/lib/rustlib, which does not exist.

To work around this, Ubuntu deploys a downstream patch. But as discussed with @bjorn3, 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.

Version it worked on

It most recently worked on: Rust 1.66.1

Version with regression

1.67

[apiraino]

Additional context from the linked u.r.l.o forum:

I think improve filesearch::get_or_default_sysroot r=ozkanonur · rust-lang/rust@71a3a48 · GitHub assumes librustc_driver.so will be in $sysroot/lib, while in your case it would be in $sysroot/lib/x86_64-linux-gnu. It should probably use the CFG_LIBDIR_RELATIVE env var set during compilation of rustc. The relevant code existed before this commit but was previously only used for finding the location of codegen backends other than LLVM. As LLVM is the only backend available on stable this didn't cause any issues until this commit which reuses the same logic for finding the sysroot (which in your case is /usr but ends up getting calculated as /usr/lib) Please open an issue to track a fix.

and

The correct fix would be to take cfg!("CFG_LIBDIR_RELATIVE") into account to find the sysroot from the librustc_driver.so location.

cc: @ozkanonur

[onur-ozkan]

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.

[onur-ozkan]

Just remember we have already patched sys detection for supporting multiarch systems.

Related commit 2186358

It's added to 1.69.0 milestone.

[cheese]

Just remember we have already patched sys detection for supporting multiarch systems.

Related commit 2186358

It's added to 1.69.0 milestone.

Oh! The same author of the Ubuntu patch.

[nc7s]

Hi, I'm experiencing the same issue when packaging 1.67 for Debian. 2186358 as mentioned by @ozkanonur didn't work. The fix is behind a check dir.ends_with(crate::config::host_triple()), which evaluates to false because host_triple() is x86_64-unknown-linux-gnu on x86_64 and dir is /usr/lib/x86_64-linux-gnu, where Debian installs multi-arch libs for x86_64. I'm testing with a || clause that simply checks against host_triple().replace("-unknown", ""), but open to better solutions.

[onur-ozkan]

Hi, I'm experiencing the same issue when packaging 1.67 for Debian. 2186358 as mentioned by @ozkanonur didn't work. The fix is behind a check dir.ends_with(crate::config::host_triple()), which evaluates to false because host_triple() is x86_64-unknown-linux-gnu on x86_64 and dir is /usr/lib/x86_64-linux-gnu, where Debian installs multi-arch libs for x86_64. I'm testing with a || clause that simply checks against host_triple().replace("-unknown", ""), but open to better solutions.

How did you test that patch? It's not shipped with 1.67

[nc7s]

How did you test that patch? It's not shipped with 1.67

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.

[onur-ozkan]

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.

[nc7s]

A deeper look concluded my previous finding partially wrong.

In default_from_rustc_driver_dll(), before the aforementioned check, two levels are unconditionally chopped off from the path of librustc_driver-*.so. On Debian it's currently installed to /usr/lib/x86_64-linux-gnu/librustc_driver-*.so, so after that dir becomes /usr/lib. The check will, of course, evaluate to false, because there's no more arch specific directory on the path.

The comment line "dll 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 https://salsa.debian.org/ncts/rust/-/commit/92d0b8f4aeb38f26803cf11ab8af0cfdb653796b.

[onur-ozkan]

I have tested this on Debian 11, worked just fine. It's under review progress now.

[nc7s]

I see, thanks for the help 🥂 I'll cherry-pick that then.