cross metadata target_dir does not match target dir used during build

[demurgos]

Checklist

• I've looked through the issues and pull requests for similar reports

Describe your issue

Running CROSS_REMOTE=1 cross metadata prints /target as the target_directory value. This does not match the directory used in practice.

What target(s) are you cross-compiling for?

No response

Which operating system is the host (e.g computer cross is on) running?

• macOS
• Windows
• Linux / BSD
• other OS (specify in description)

What architecture is the host?

• x86_64 / AMD64
• arm32
• arm64 (including Mac M1)

What container engine is cross using?

• docker
• podman
• other container engine (specify in description)

cross version

cross 0.2.5 (4282f2f 2023-12-27)

Example

I am writing a script to automate cross-compilation of [one of my projects]. As part of this, I want to find the output binary and move copy it for packaging.
To achieve this, I run cross build with the --message-format=json option to get the build path. In my case, cross build yields "/cross/data/projects/eternaltwin/etwin/bin/target/x86_64-unknown-linux-gnu/release/eternaltwin".

{
  "reason": "compiler-artifact",
  "package_id": "eternaltwin 0.13.0 (path+file:///cross/data/projects/eternaltwin/etwin/bin)",
  "manifest_path": "/cross/data/projects/eternaltwin/etwin/bin/Cargo.toml",
  "target": {
    "name": "eternaltwin",
    "kind": [
      "bin"
    ],
    "crate_types": [
      "bin"
    ],
    "required-features": [],
    "src_path": "/cross/data/projects/eternaltwin/etwin/bin/src/main.rs",
    "edition": "2021",
    "doctest": false,
    "test": true,
    "doc": true
  },
  "profile": {
    "opt_level": "z",
    "debuginfo": 0,
    "debug_assertions": false,
    "overflow_checks": false,
    "test": false
  },
  "features": [],
  "filenames": [
    "/cross/data/projects/eternaltwin/etwin/bin/target/x86_64-unknown-linux-gnu/release/eternaltwin"
  ],
  "executable": "/cross/data/projects/eternaltwin/etwin/bin/target/x86_64-unknown-linux-gnu/release/eternaltwin",
  "fresh": false
}

This implies that the target directory used by the build is /cross/data/projects/eternaltwin/etwin/bin/target. However, when I run CROSS_REMOTE=1 cross metadata then I get /target for the target directory.

https://gist.github.com/demurgos/77188279ee51de1f5af06d22c020b045

This discrepancy makes it impossible to reliably find the path of the executable relative to the target directory.

Additional information / notes

Also tested on

$ cross --version
cross 0.2.5 (202013b 2023-03-24)
[cross] note: Falling back to `cargo` on the host.
cargo 1.75.0 (1d8b05cdd 2023-11-20)

This was the first version with a fix for #1218; but the issue is already present there.

[Emilgardis]

I'm a bit confused as to what you expect this to do. The path reported is correct for the binaries running inside the container engine, and I dont see how we would be able to change it since all we do is call cargo metadata

[demurgos]

I expect cross metadata and cross build to use the same target directory. I may be missing something, but if cross metadata returns /target, then why are the events sent by cross build not referencing /target?

[Emilgardis]

They are referencing the same directory. Just mounted differently in the container.

[demurgos]

Taking a step back, my issue is that I want to retrieve the path of the binary after cross build has finished and avoid hard-coding if possible. What's the best way to achieve it?

My idea is the following: the host and container target directories are mapped. I can query cargo metadata on the host and cross metadata for the container to know the host/container paths of the target dir. During the build, I get the binary path inside the container, and since I know the target dir mapping I can replace the prefix to get the path on the host.

However, for this to work; the target dir must be mounted in the same place for both cross metadata and cross build. Is there a way to achieve it? Why are they mounted differently between both commands?

I posted the full commands and logs at https://gist.github.com/demurgos/77188279ee51de1f5af06d22c020b045

[Emilgardis]

I'll look into this a bit more, I think you may be correct that this is unexpected. Ideally though, this should probably be done with cross-util install --root