Skip to content

library metadata is build path dependant and so not portable #39786

Closed
@semarie

Description

@semarie

Hi,

At OpenBSD, we are facing a packaging problem that seems to be related to the way library filename (and metadata hash) is builded.

The metadata (and the filename, as it is {filename}-{target_metadata}) is constructed by hashing using several parameters to ensuring an unique name reflecting compatibility.

Per se, it is cargo that construct the metadata information (see target_metadata() function). But as it affects rustc packaging, I prefer to open an issue against rustc.

The metadata hash is based on several components.

Here an debug output of some elements of these components (output based on local patch of cargo, used when building rustc):

package_id=PackageId {
  name: "std_shim",
  version: "0.1.0",
  source: "file:///home/semarie/ports/pobj/rust-1.15.1/rustc-1.15.1-src/src/rustc/std_shim"
}

profile=Profile {
  opt_level: "2",
  lto: false,
  codegen_units: None,
  rustc_args: None,
  rustdoc_args: None,
  debuginfo: false,
  debug_assertions: false,
  rpath: false,
  test: false,
  doc: false,
  run_custom_build: false,
  check: false,
  panic: None
}

target.name="std_shim"
target.kind=Lib([Lib])

The PackageId contains elements related to the build host configuration: the full path of the source tree used at build-time. It should be at least the relative path.

Additionally profile could included several informations related to the host that build the library but not about the library itself, like rustc_args, or codegen_units which is a LLVM parameter that shouldn't influence the library compatibility.

Per se, it is a portability issue: the metadata information shouldn't depend on information that Rust doesn't control (and the full path of the build directory isn't controlled).

OpenBSD exposes the problem because as the build of package is based on work of voluntary persons (openbsd developers), build hosts aren't necessary homogeneous regarding the build environment (build path could vary). It makes filename of libraries (which include the metadata information) to differ from one build to another, and so we are unable to package it properly.

I assume the metadata hash should be constructed with some elements from packageid or profile but not from all. Or a preprocessing should be done on elements that could contains pathnames in order to exclude the build directory part from it (and rely only on rust-owned stuff).

I would also point that some discussion about it occurs on #rust-internals.

Metadata

Metadata

Assignees

No one assigned

    Labels

    C-enhancementCategory: An issue proposing an enhancement or a PR with one.T-dev-toolsRelevant to the dev-tools subteam, which will review and decide on the PR/issue.

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions