Is library path canonicalization worth it?

compiler
1

I’m trying to fix the same problem I tried to fix in https://github.com/rust-lang/rust/pull/29433.

The problem is that find_library_crate calls fs::canonicalize on found library paths, but then the resulting path is passed to get_metadata_section, which assumes it will end in “.rlib” if it’s an rlib.

My build system has links like:

libstd-db5a760f.rlib -> /network/cas/8332e6723d11b5b4d793f56160b626c7f6ae8edc

So get_metadata_section doesn’t see .rlib, tries to read it as a dylib, and fails mysteriously.

There are a few solutions that I can see:

  1. Pass the “flavor” (rlib vs dylib) into get_metadata_section.
  2. Change from PathBuf to something that bundles up PathBuf with flavor.
  3. Don’t canonicalize if the resulting filename doesn’t end in .rlib or whatever.

None of these make me happy. In fact, the more I look at it, the less I feel like we should be using canonical paths at all.

Why we complain about multiple paths found to the same exact hash? Right now, we complain unless they’re symlinks to the same base path (changed due to issue 12459), but that doesn’t seem particularly helpful. If someone wants to somehow put different libraries with the same hash around, and they get weird behavior, is that honestly something we need to catch?

2

This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.