Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Building v1.1.0 results in a filename collision #1548

Closed
aperture-sandi opened this issue Sep 13, 2023 · 25 comments
Closed

Building v1.1.0 results in a filename collision #1548

aperture-sandi opened this issue Sep 13, 2023 · 25 comments
Labels
I10-unconfirmed Issue might be valid, but it's not yet known.

Comments

@aperture-sandi
Copy link

aperture-sandi commented Sep 13, 2023

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>.
@github-actions github-actions bot added the I10-unconfirmed Issue might be valid, but it's not yet known. label Sep 13, 2023
@gregorst3
Copy link

gregorst3 commented Sep 14, 2023

I'm having the same problem by compiling for znver3

@mrcnski
Copy link
Contributor

mrcnski commented Sep 14, 2023

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 mrcnski closed this as completed Sep 14, 2023
@mrcnski
Copy link
Contributor

mrcnski commented Sep 14, 2023

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

@mrcnski
Copy link
Contributor

mrcnski commented Sep 14, 2023

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
Copy link
Author

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
Copy link
Contributor

mrcnski commented Sep 14, 2023

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
Copy link
Author

aperture-sandi commented Sep 14, 2023

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
Copy link
Contributor

mrcnski commented Sep 14, 2023

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
Copy link
Author

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

@bernardoaraujor
Copy link
Contributor

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
Copy link
Contributor

mrcnski commented Oct 17, 2023

@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
Copy link
Contributor

bernardoaraujor commented Oct 17, 2023

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 <admin@parity.io>, 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
Copy link
Contributor

mrcnski commented Oct 17, 2023

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
Copy link
Contributor

mrcnski commented Oct 17, 2023

@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
Copy link
Contributor

yes, just reproduced again with a fresh git clone

@wirednkod
Copy link
Contributor

wirednkod commented Oct 18, 2023

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
Copy link
Contributor

mrcnski commented Oct 18, 2023

I was able to reproduce. 👀

@mrcnski
Copy link
Contributor

mrcnski commented Oct 18, 2023

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:

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

@bkchr
Copy link
Member

bkchr commented Oct 18, 2023

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
Copy link
Contributor

mrcnski commented Oct 18, 2023

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
Copy link
Member

bkchr commented Oct 18, 2023

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
Copy link
Contributor

mrcnski commented Oct 18, 2023

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
Copy link
Contributor

mrcnski commented Oct 18, 2023

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

@wirednkod
Copy link
Contributor

@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
Copy link
Contributor

mrcnski commented Oct 19, 2023

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
I10-unconfirmed Issue might be valid, but it's not yet known.
Projects
None yet
Development

No branches or pull requests

6 participants