Building v1.1.0 results in a filename collision #1548

aperture-sandi · 2023-09-13T23:05:10Z

Building v1.1.0 via RUSTFLAGS="-C target-cpu=native" ~/.cargo/bin/cargo build --release
results in a filename collision (below) which results in "this error" when running: polkadot --chain polkadot --validator

"this error" -> Error: 0: ESC[91mVersion of worker binary (1.0.0-f60318f6868) is different from node version (1.1.0-f60318f6868), worker_path: ~/polkadot-sdk/target/release/polkadot-prepare-worker. If you ran with `cargo run`, please run `cargo build` first, otherwise try to `cargo clean`. TESTING ONLY: this check can be disabled with --disable-worker-version-checkESC[0m

filename collision...

warning: output filename collision.
The bin target `polkadot-execute-worker` in package `polkadot-test-malus v1.0.0 (~/polkadot-sdk/polkadot/node/malus)` has the same output filename as the bin target `polkadot-execute-worker` in package `polkadot v1.1.0 (~/polkadot-sdk/polkadot)`.
Colliding filename is: ~/polkadot-sdk/target/release/polkadot-execute-worker
The targets should have unique names.
Consider changing their names to be unique or compiling them separately.
This may become a hard error in the future; see <https://github.com/rust-lang/cargo/issues/6313>.
warning: output filename collision.
The bin target `polkadot-execute-worker` in package `polkadot-test-malus v1.0.0 (~/polkadot-sdk/polkadot/node/malus)` has the same output filename as the bin target `polkadot-execute-worker` in package `polkadot v1.1.0 (~/polkadot-sdk/polkadot)`.
Colliding filename is: ~/polkadot-sdk/target/release/polkadot-execute-worker.dwp
The targets should have unique names.
Consider changing their names to be unique or compiling them separately.
This may become a hard error in the future; see <https://github.com/rust-lang/cargo/issues/6313>.
warning: output filename collision.
The bin target `polkadot-prepare-worker` in package `polkadot-test-malus v1.0.0 (~/polkadot-sdk/polkadot/node/malus)` has the same output filename as the bin target `polkadot-prepare-worker` in package `polkadot v1.1.0 (~/polkadot-sdk/polkadot)`.
Colliding filename is: ~/polkadot-sdk/target/release/polkadot-prepare-worker
The targets should have unique names.
Consider changing their names to be unique or compiling them separately.
This may become a hard error in the future; see <https://github.com/rust-lang/cargo/issues/6313>.
warning: output filename collision.
The bin target `polkadot-prepare-worker` in package `polkadot-test-malus v1.0.0 (~/polkadot-sdk/polkadot/node/malus)` has the same output filename as the bin target `polkadot-prepare-worker` in package `polkadot v1.1.0 (~/polkadot-sdk/polkadot)`.
Colliding filename is: ~/polkadot-sdk/target/release/polkadot-prepare-worker.dwp
The targets should have unique names.
Consider changing their names to be unique or compiling them separately.
This may become a hard error in the future; see <https://github.com/rust-lang/cargo/issues/6313>.

The text was updated successfully, but these errors were encountered:

gregorst3 · 2023-09-14T07:05:58Z

I'm having the same problem by compiling for znver3

mrcnski · 2023-09-14T11:43:20Z

Thanks for the report! It's just a warning and can be ignored.

More info here: #1154 (comment)

Closing in favor of #1154. Please feel free to respond there.

mrcnski · 2023-09-14T11:49:08Z

As I noted on #1154, I'll try to fix this by the next release. For now, please just ignore the warning. Apologies!

mrcnski · 2023-09-14T11:53:20Z

Oh, I didn't see the version mismatch error. Yes, that's a hard error. Did you read the release notes? 😉 You'll need to re-visit our installation instructions as they have changed.

aperture-sandi · 2023-09-14T13:34:45Z

Thanks for the reply. The only difference I see here https://wiki.polkadot.network/docs/maintain-guides-how-to-validate-polkadot is building with the production flag instead of release flag. Is that our issue?

mrcnski · 2023-09-14T13:41:16Z

Which section there are you following? I tried to update every section but maybe I missed one. The issue is there are now some extra binaries that you have to build as well. The easiest way to do it is cargo install in place of cargo build. I'd uninstall polkadot first, to avoid any conflicts with cargo's installation.

And yeah, I'd recommend building with the production profile, unless you have a good reason not to. :)

aperture-sandi · 2023-09-14T14:27:57Z

In the #optional-building-the-polkadot-binaries-from-sources section it still says to
git clone https://github.com/paritytech/polkadot.git instead of polkadot-sdk.git
When running cargo install --force --path . --profile production from /home/<user>/polkadot-sdk I get error:
found a virtual manifest at `/home/<user>/polkadot-sdk/Cargo.toml` instead of a package manifest

mrcnski · 2023-09-14T14:37:29Z

Good catch! ⭐️ The page was updated after new binaries were introduced, but then not after the monorepo migration. I'm on it. For now, You'll have to run cargo install <...> from /home/<user>/polkadot-sdk/polkadot. Let me know if anything else comes up!

aperture-sandi · 2023-09-14T14:57:19Z

Ah ha! Got it! Thanks for the help! 🚀

bernardoaraujor · 2023-10-17T13:23:59Z

I'm having a similar issue, trying to build v1.1.0 for MacOS but polkadot-execute-worker binary is still on v1.0.0, which prevents the relay from starting

mrcnski · 2023-10-17T15:04:15Z

@bernardoaraujor Some more info would help. How are you building/installing? If the worker binary is out of date, then failing to start a validator node is expected behavior.

bernardoaraujor · 2023-10-17T15:19:12Z

my build steps are:

git clone https://github.com/paritytech/polkadot-sdk/
cd polkadot-sdk
git checkout tags/polkadot-v1.1.0
cargo build --release

as a result I get:

./target/release/polkadot-execute-worker --version
1.1.0-f60318f6868
./target/release/polkadot-prepare-worker --version
1.0.0-f60318f6868
./target/release/polkadot --version
polkadot 1.1.0-f60318f6868

and when I try to spawn a network via zombienet:

2023-10-17 12:21:25 Parity Polkadot
2023-10-17 12:21:25 ✌️  version 1.1.0-f60318f6868
2023-10-17 12:21:25 ❤️  by Parity Technologies <[email protected]>, 2017-2023
2023-10-17 12:21:25 📋 Chain specification: Rococo Local Testnet
2023-10-17 12:21:25 🏷  Node name: dave
2023-10-17 12:21:25 👤 Role: AUTHORITY
2023-10-17 12:21:25 💾 Database: RocksDb at /var/folders/0n/4nqy69197mdfz6tz2sbrpwcm0000g
n/T/zombie-cc40c8e16217f6e2e80cf51eea4d8d60_-77628-5NaZ0CuxMYte/dave/data/chains/rococo_l
ocal_testnet/db/full
2023-10-17 12:21:28 🔨 Initializing Genesis block/state (state: 0xf408…9453, header-hash: 0xf11a…d6f3)
2023-10-17 12:21:28 👴 Loading GRANDPA authority set from genesis on what appears to be first startup.
2023-10-17 12:21:29 👶 Creating empty BABE epoch changes on what appears to be first startup.
2023-10-17 12:21:29 🏷  Local node identity is: 12D3KooWKM1HeSv61ryZwAiBTZnqmass5pYM48k9Z7obzhTbnphm
Error:
   0: Version of worker binary (1.0.0-f60318f6868) is different from node version (1.1.0-f60318f6868), worker_path: /Users/bear/develop/mythical-node/bin/polkadot-prepare-worker. If you ran with `cargo run`, please run `cargo build` first, otherwise try to `cargo clean`. TESTING ONLY: this check can be disabled with --disable-worker-version-check

  ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ BACKTRACE ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
   1: backtrace::capture::Backtrace::new::heb2795d6edaddb0a
      at <unknown source file>:<unknown line>
   2: color_eyre::config::EyreHook::into_eyre_hook::{{closure}}::h9ec6cf5c9890f05b
      at <unknown source file>:<unknown line>
   3: eyre::capture_handler::h579943842574657d
      at <unknown source file>:<unknown line>
   4: polkadot::main::h8e71f3822a664022
      at <unknown source file>:<unknown line>
   5: std::sys_common::backtrace::__rust_begin_short_backtrace::hfcf9e1e4845cbe9c
      at <unknown source file>:<unknown line>
   6: std::rt::lang_start::{{closure}}::h9fec226cf6b34160
      at <unknown source file>:<unknown line>
   7: core::ops::function::impls::<impl core::ops::function::FnOnce<A> for &F>::call_once::hcb04887f0e2b52c1
      at /rustc/5680fa18feaa87f3ff04063800aec256c3d4b4be/library/core/src/ops/function.rs:284
   8: std::panicking::try::do_call::h414ee3c827cba447
      at /rustc/5680fa18feaa87f3ff04063800aec256c3d4b4be/library/std/src/panicking.rs:500
   9: std::panicking::try::hdc18bc856569c3fb
      at /rustc/5680fa18feaa87f3ff04063800aec256c3d4b4be/library/std/src/panicking.rs:464
  10: std::panic::catch_unwind::h3da89e4412af48ed
      at /rustc/5680fa18feaa87f3ff04063800aec256c3d4b4be/library/std/src/panic.rs:142
  11: std::rt::lang_start_internal::{{closure}}::h2e9bee3cbb426940
      at /rustc/5680fa18feaa87f3ff04063800aec256c3d4b4be/library/std/src/rt.rs:148
  12: std::panicking::try::do_call::h43a0fdba16541c76
      at /rustc/5680fa18feaa87f3ff04063800aec256c3d4b4be/library/std/src/panicking.rs:500
  13: std::panicking::try::hcff632d46e2a16c0
      at /rustc/5680fa18feaa87f3ff04063800aec256c3d4b4be

mrcnski · 2023-10-17T15:34:58Z

Did you try cargo clean as indicated in the error message? I think there is a cargo bug where it sometimes will not re-build the auxiliary binaries, but wiping everything and starting over usually works.

mrcnski · 2023-10-17T16:34:42Z

@bernardoaraujor Did you really start with a fresh git clone? Both workers pull in the same polkadot_cli::NODE_VERSION for the version, so it would be very strange if a fresh build resulted in mismatched versions. 🤔

bernardoaraujor · 2023-10-17T16:38:00Z

yes, just reproduced again with a fresh git clone

wirednkod · 2023-10-18T09:10:12Z

FWIW I did the same from a fresh clone and got different results (which is extremelly strange):

➜ ./target/release/polkadot-execute-worker --version
1.0.0-f60318f6868

➜ ./target/release/polkadot-prepare-worker --version
1.1.0-f60318f6868

➜ ./target/release/polkadot --version
polkadot 1.1.0-f60318f6868

EDIT: after a cargo clean and rebuild with --release the results are again different:

➜ ./target/release/polkadot-execute-worker --version
1.0.0-f60318f6868

➜ ./target/release/polkadot-prepare-worker --version
1.0.0-f60318f6868

➜ ./target/release/polkadot --version
polkadot 1.1.0-f60318f6868

mrcnski · 2023-10-18T12:49:13Z

I was able to reproduce. 👀

mrcnski · 2023-10-18T12:55:39Z

On the v1.1.0 tag we are still getting the version from an env var instead of a constant:

https://github.com/paritytech/polkadot-sdk/blob/polkadot-v1.1.0/polkadot/src/bin/prepare-worker.rs#L22

So I see two issues here:

There is some bug with SUBSTRATE_CLI_IMPL_VERSION. It sometimes gets the wrong version, plus it behaves non-deterministically. (cc @bkchr)
The PR Make the node version independent of the crate version #1495 did not make it into v1.1.0. (cc @coderobe)

bkchr · 2023-10-18T13:05:02Z

The pr was created after 1.1.0 was released or was in the process of getting released. The idea was never to have it in this release.

mrcnski · 2023-10-18T13:05:35Z

Looks like we get the version part from CARGO_PKG_VERSION:

https://github.com/paritytech/polkadot-sdk/blob/polkadot-v1.1.0/substrate/utils/build-script-utils/src/version.rs#L52

So I guess this is some bug in cargo? So we just need to get a fix into 1.1.0 or do a fix + patch bump to 1.1.1.

bkchr · 2023-10-18T13:06:27Z

There is some bug with SUBSTRATE_CLI_IMPL_VERSION. It sometimes gets the wrong version, plus it behaves non-deterministically. (cc @bkchr)

What does it mean that it gets the wrong version? What version does it return?

mrcnski · 2023-10-18T13:07:20Z

There is some bug with SUBSTRATE_CLI_IMPL_VERSION. It sometimes gets the wrong version, plus it behaves non-deterministically. (cc @bkchr)

What does it mean that it gets the wrong version? What version does it return?

It sometimes returns the old version 1.0.0, but it's not deterministic. See:

mrcnski · 2023-10-18T16:59:25Z

Has someone tried v1.2.0 and is the issue fixed there?

wirednkod · 2023-10-18T17:11:08Z

@mrcnski Just tried v1.2.0 and the results can be seen below:

➜  polkadot-sdk git:(polkadot-v1.2.0) ./target/release/polkadot --version
polkadot 1.2.0-72c45356393

➜  polkadot-sdk git:(polkadot-v1.2.0) ./target/release/polkadot-prepare-worker --version
1.2.0

➜  polkadot-sdk git:(polkadot-v1.2.0) ./target/release/polkadot-execute-worker --version
1.2.0

mrcnski · 2023-10-19T09:01:00Z

Going to close as it should be fixed on v1.2.0. Please re-open if not!

github-actions bot added the I10-unconfirmed Issue might be valid, but it's not yet known. label Sep 13, 2023

mrcnski closed this as completed Sep 14, 2023

bernardoaraujor reopened this Oct 17, 2023

mrcnski closed this as completed Oct 19, 2023

ghost mentioned this issue Jan 5, 2024

Match node version with tag version freeverseio/laos#270

Merged

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Building v1.1.0 results in a filename collision #1548

Building v1.1.0 results in a filename collision #1548

aperture-sandi commented Sep 13, 2023 •

edited

Loading

gregorst3 commented Sep 14, 2023 •

edited

Loading

mrcnski commented Sep 14, 2023

mrcnski commented Sep 14, 2023

mrcnski commented Sep 14, 2023

aperture-sandi commented Sep 14, 2023

mrcnski commented Sep 14, 2023

aperture-sandi commented Sep 14, 2023 •

edited

Loading

mrcnski commented Sep 14, 2023

aperture-sandi commented Sep 14, 2023

bernardoaraujor commented Oct 17, 2023

mrcnski commented Oct 17, 2023

bernardoaraujor commented Oct 17, 2023 •

edited

Loading

mrcnski commented Oct 17, 2023

mrcnski commented Oct 17, 2023

bernardoaraujor commented Oct 17, 2023

wirednkod commented Oct 18, 2023 •

edited

Loading

mrcnski commented Oct 18, 2023

mrcnski commented Oct 18, 2023

bkchr commented Oct 18, 2023

mrcnski commented Oct 18, 2023 •

edited

Loading

bkchr commented Oct 18, 2023

mrcnski commented Oct 18, 2023

mrcnski commented Oct 18, 2023

wirednkod commented Oct 18, 2023

mrcnski commented Oct 19, 2023

Building v1.1.0 results in a filename collision #1548

Building v1.1.0 results in a filename collision #1548

Comments

aperture-sandi commented Sep 13, 2023 • edited Loading

gregorst3 commented Sep 14, 2023 • edited Loading

mrcnski commented Sep 14, 2023

mrcnski commented Sep 14, 2023

mrcnski commented Sep 14, 2023

aperture-sandi commented Sep 14, 2023

mrcnski commented Sep 14, 2023

aperture-sandi commented Sep 14, 2023 • edited Loading

mrcnski commented Sep 14, 2023

aperture-sandi commented Sep 14, 2023

bernardoaraujor commented Oct 17, 2023

mrcnski commented Oct 17, 2023

bernardoaraujor commented Oct 17, 2023 • edited Loading

mrcnski commented Oct 17, 2023

mrcnski commented Oct 17, 2023

bernardoaraujor commented Oct 17, 2023

wirednkod commented Oct 18, 2023 • edited Loading

mrcnski commented Oct 18, 2023

mrcnski commented Oct 18, 2023

bkchr commented Oct 18, 2023

mrcnski commented Oct 18, 2023 • edited Loading

bkchr commented Oct 18, 2023

mrcnski commented Oct 18, 2023

mrcnski commented Oct 18, 2023

wirednkod commented Oct 18, 2023

mrcnski commented Oct 19, 2023

aperture-sandi commented Sep 13, 2023 •

edited

Loading

gregorst3 commented Sep 14, 2023 •

edited

Loading

aperture-sandi commented Sep 14, 2023 •

edited

Loading

bernardoaraujor commented Oct 17, 2023 •

edited

Loading

wirednkod commented Oct 18, 2023 •

edited

Loading

mrcnski commented Oct 18, 2023 •

edited

Loading