Hi,
I found something interesting. I realized that between the working
version vs the non-working version, the packaging had changed, from a
forked version of dh-cargo to the now standard dh-rust. Building the new upstream version with the old packaging works fine. What's more, it
makes it possible to compare the building flags that work vs those that
don't work.
The forked dh-cargo (working) version includes these flags when building
the code with rustc, which are not included with the dh-rust
(non-working) version:
-C debuginfo=2 --cap-lints warn -C linker=x86_64-linux-gnu-gcc -C link-arg=-Wl,-z,relro
--remap-path-prefix debian/cargo_registry=/usr/share/cargo/registry/ -Ctarget-cpu=native`
Particularly interesting is the last one, target-cpu=native. I looked
around, trying to find where that is coming from, and found that
upstream's .cargo/config.toml file says this:
[build]
# This can cause weirdness if they don't match!
rustflags = ["-Ctarget-cpu=native"]
rustdocflags = ["-Ctarget-cpu=native"]
I think the weirdness we are seeing is exactly due to the fact that they
don't match. So, the next question is why dh-rust is not picking up this variable anymore. I found that the generated
debian/cargo_home/config.toml file used to include a [build] section,
where now it uses [target.'cfg(all())']. I tried adding this section to
the .cargo/config.toml file, but that didn't make a difference.
I also tried modifying the dh-rust cargo code to generate the build
section in the config.toml, and in an act of desperation even tried
hard-coding the flags there, and it still didn't use it when building...
Eventually I noticed that the logs from the working version included
this line that was not present in the other log:
debian cargo wrapper: unsetting RUSTFLAGS and assuming it will be (or
already was) added to $CARGO_HOME/config
So, I tried adding the piece of code that does that to the cargo command
from dh-rust:
if "RUSTFLAGS" in os.environ:
# see
https://github.com/rust-lang/cargo/issues/6338 for
explanation on why we must do this
log("unsetting RUSTFLAGS and assuming it will be (or already
was) added to $CARGO_HOME/config")
extra_rustflags = os.environ["RUSTFLAGS"]
del os.environ["RUSTFLAGS"]
else:
extra_rustflags = ""
And, as long as the sections in both config.toml files match, then it
works.
So, in order to make it work, we need to add in .cargo/config.toml (so
that it matches the new format):
[target.'cfg(all())']
rustflags = ["-Ctarget-cpu=native"]
And we need to unset the RUSTFLAGS before calling the cargo command.
However, this is not easy to achieve without modifying the code of that dh-rust/cargo script. I've tried overriding the calls to dh in several
ways and I didn't manage to get the same behavior.
What I did find, though, was that removing the [build] section from the .cargo/config.toml file (basically leaving that file empty) and adding
an undefine RUSTFLAGS line to debian/rules lets the package build
successfully, but the amount of tests it runs is smaller and it doesn't
include the target-cpu=native flag.
This approach would make it possible for the package to build, but I
fear it's not really correct, as it's not running all of the test as the package used to run before.
Apart from the cargo issue mentioned on that piece of code, there's this
other issue where the problem with rust flags not being cumulative is
also discussed. And in that issue the target.'cfg(all())' approach is suggested:
https://github.com/rust-lang/cargo/issues/5376
This feels like being just a few meters from the goal, but I can't
figure out how to get the right unsetting behavior through debian/rules.
:(
--
Regards,
Marga
--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)