[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#1116695: dh-rust generally uses the build architecture compiler for linking



Package: dh-rust
Version: 0.0.11
Severity: important
Justification: breaks cross building of several packages
Control: affects -1 + src:btm src:precious src:resvg
User: debian-cross@lists.debian.org
Usertags: ftcbfs
X-Debbugs-Cc: debian-cross@lists.debian.org, debian-rust@lists.debian.org
Control: block 1112299 by -1

Hi Jonas and Fabian,

earlier, I reported a cross build failure #1112299 in resvg and observed 
that it was using the build architecture compiler as linker. I now 
recognize this as a pattern also affecting btm and precious and probably 
more. A common pattern is that they all use dh-rust. I checked a number 
of dh-rust using packages and found none that would actually cross 
build. The vast majority is bd-uninstallable due to some toolchain 
conflict (e.g. librust-tree-sitter-dev depending on rustc is bad or llvm 
finally dropped their incorrect m-a:same annotations). The few where a 
build is attempted either fail to understand the triplet passed to 
-target (often a sign for missing libstd-rust-dev) or fail when they 
link with the wrong C compiler.

I still do not understand why this is happening. This is what I wrote in 
the earlier #1112299 bug report:

> Next up, it uses the build architecture compiler for linking the resvg
> executable. I spent some time trying to understand why an asked Fabian
> for help, but I wasn't able to figure out the root cause. I confirm,
> that dh-rust correctly inserts -C linker=... into the config.toml in
> section [target.'cfg(all())'], but the actual linker invocation lacks
> both the supplied linker and link-arg. I note that dh-cargo uses a
> different section [build], but changing the section to match dh-cargo's
> does not fix the problem. Would someone else see what the problem is
> here?

Would someone have suggestions on how to debug this? You should be able 
to reproduce this as simple as "sbuild -d unstable --host riscv64 
$somepackage" using one of the affected ones.

Helmut


Reply to: