Package: cargo
Version: 0.57.0-7+b1
Severity: normal
Dear Maintainer,
Short description:
This bug mostly boils down to a incompatibility of the cargo wrapper script and
external build tools, that call the wrapper script. Which causes `cargo` to be
called with two identical `--target` command line parameters, one from the
external build tool, and one from the wrapper script. This causes the build to
fail with:
error: specifying multiple `--target` flags requires `-Zmultitarget`
Long description:
Some software project that have Rust code embedded into them use third-party
build tools, like for instance with Python `setuptools-rust`. Those ordinarily
just call `cargo` with some command line parameters to build the Rust code.
The `/usr/share/cargo/bin/cargo` script is a wrapper script, that simplifies
packaging of Rust software for Debian and takes care about creating and using
local Rust software registries. So that all Rust dependencies come from Debian
packages instead directly from crates.io. The wrapper scripts configures the
build environment and then calls `cargo` with some additional command line
parameters to build the Rust code.
Combining those two software pieces would mean that `setuptools-rust` calls the
wrapper script instead of cargo directly. Because `setuptools-rust` is part of a
bigger build process that processes other code, like in this case Python code,
in addition to just the Rust part.
Because the cargo wrapper script adds the `--target $DEB_HOST_RUST_TYPE` to its
call to `cargo`, `cargo` generates the binaries to different paths and
`setuptools-rust` will no longer find them.
If `setuptools-rust` is configured with the same rust target, so that in
searches for the right path for those binaries, it adds a `--target` parameter
as well. In that case the wrapper script is called with a `--target` parameter,
which it just hands of to cargo, but it also adds its own `--target`
parameter. Now cargo is called with two `--target` parameters, and it complains
about those with the error:
error: specifying multiple `--target` flags requires `-Zmultitarget`
Expected outcome:
The cargo wrapper script should be as transparent as possible, there are a
couple of options to resolve this:
- If the cargo wrapper script is called without `--target` parameters, the
path where the binaries are generated to, should be the same as if `cargo` is
called without `--target` parameter.
I think this would be a proper solution, however it would break backwards
compatibility
- If the cargo wrapper script is called with a `--target` parameter, it should
check whether the target is the same, an discard one, or complain if they are
different.
This would require that build tools like `setuptools-rust` need to support
defining rust targets on there own, and know where to look for the binaries
if both cases, but the fix would be backwards compatible, because it only
fixes the issue if the wrapper script is called with a `--target` parameter,
which currently just fails.
regards,
Claudius
-- System Information:
Debian Release: bookworm/sid
APT prefers unstable
APT policy: (500, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 5.18.0-4-amd64 (SMP w/8 CPU threads; PREEMPT)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8),
LANGUAGE=en_US:en
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
Versions of packages cargo depends on:
ii binutils 2.38.90.20220713-2
ii clang 1:14.0-55.1
ii clang-13 [c-compiler] 1:13.0.1-7
ii clang-14 [c-compiler] 1:14.0.6-2
ii gcc [c-compiler] 4:12.1.0-3
ii gcc-10 [c-compiler] 10.4.0-4
ii gcc-11 [c-compiler] 11.3.0-5
ii gcc-12 [c-compiler] 12.2.0-1
ii gcc-9 [c-compiler] 9.5.0-2
ii libc6 2.34-7
ii libcurl3-gnutls 7.84.0-2
ii libgcc-s1 12.2.0-1
ii libgit2-1.3 1.3.0+dfsg.1-3
ii libssh2-1 1.10.0-3+b1
ii libssl3 3.0.5-2
ii rustc 1.59.0+dfsg1-2
ii zlib1g 1:1.2.11.dfsg-4.1
cargo recommends no packages.
Versions of packages cargo suggests:
pn cargo-doc <none>
ii python3 3.10.6-1
-- no debconf information
