Linker error between subxt and sp dependencies

[nakul1010]

After updating the subxt dependency to the latest version in the repository, and also updating the sp dependencies based on the subxt repo, a linker error issue is emitted.

Code hyperlink

Command to run: cargo b -p runtime --features parachain-metadata-kintsugi-testnet

Error Message

error: linking with `cc` failed: exit status: 1

The complete error message can be found in the CI logs here

[niklasad1]

@nakul1010

You have two different versions of wasmtime in your dependency tree, is it possible to update the substrate dependencies to match subxt or the other way around?

[nakul1010]

@niklasad1, these are the Subxt dependencies I found for Substrate:

• sp-core = { version = "21.0.0", default-features = false }
• sp-core-hashing = "9.0.0"
• sp-keyring = "24.0.0"
• sp-runtime = "24.0.0"
• sp-version = "22.0.0"

Only for sp-version can be matched without breaking much of the code. However, this will still cause the same issue. In my opinion, the solution lies in ensuring that the dependencies' interbtc chain aligns with the Subxt dependency. additional questions, why the Subxt substrate dependency doesn't point to a specific release of Polkadot but are hardcoded to a specific version? And is there any other solution available through which the client can use the latest subxt version without updating the mentioned sp dependency?

[niklasad1]

subxt is published on crates.io and don't follow the polkadot releases and it may work for several polkadot versions etc depending whether a certain pallet had breaking changes or not.

For further info take a look at this issue

The easiest to workaround around this "mess" is to disable the substrate-compat feature if that works. Otherwise, you would need to patch your substrate dependencies.

Long-term we really depend on that polkadot/substrate crates are going to be published on crates.io on a regular schedule which is being worked on but not sure when it's going to happen.....

[nakul1010]

hey @niklasad1, I went ahead with the second option but

When trying to call submit_and_watch, I encounter an error after disabling the substrate-compat feature. I have made all the necessary modifications to ensure compatibility with our sp version. The current configuration is as follows:

impl Config for InterBtcRuntime {
    type Index = <SubstrateConfig as Config>::Index; // through subxt
    type Hash = <SubstrateConfig as Config>::Hash;// through subxt
    type AccountId = AccountId; // Type defined natively
    type Address = MultiAddress<Self::AccountId, ()>;
    type Signature = MultiSignature; // Type defined natively
    type Hasher = <SubstrateConfig as Config>::Hasher;// through subxt
    type Header = <SubstrateConfig as Config>::Header;// through subxt
    type ExtrinsicParams = PolkadotExtrinsicParams<Self>;// through subxt
}

// Pair signer defined natively
#[derive(Clone, Debug)]
pub struct PairSigner<T: Config, Pair> {
    account_id: T::AccountId,
    pub signer: Pair,
}

Error:

thread 'http::tests::test_fund_rich_user_fails' panicked at 'called `Result::unwrap()` on an `Err` value: Rpc(ClientError(Call(Custom(ErrorObject { code: ServerError(1002), message: "Verification Error: Runtime error: Execution failed: Execution aborted due to trap: wasm trap: wasm `unreachable` instruction executed\nWASM backtrace:\nerror while executing at wasm backtrace:\n    0: 0x6111f - <unknown>!rust_begin_unwind\n    1: 0xfb6d - <unknown>!core::panicking::panic_fmt::h481b2bcd87217f3b\n    2: 0x43ef05 - <unknown>!TaggedTransactionQueue_validate_transaction", data: Some(RawValue("RuntimeApi(\"Execution failed: Execution aborted due to trap: wasm trap: wasm `unreachable` instruction executed\\nWASM backtrace:\\nerror while executing at wasm backtrace:\\n    0: 0x6111f - <unknown>!rust_begin_unwind\\n    1: 0xfb6d - <unknown>!core::panicking::panic_fmt::h481b2bcd87217f3b\\n    2: 0x43ef05 - <unknown>!TaggedTransactionQueue_validate_transaction\")")) }))))', runtime/src/rpc.rs:306:76
stack backtrace:
   0: rust_begin_unwind
             at /rustc/b70baa4f922a1809d79caeaeb902800c3be283b9/library/std/src/panicking.rs:575:5
   1: core::panicking::panic_fmt
             at /rustc/b70baa4f922a1809d79caeaeb902800c3be283b9/library/core/src/panicking.rs:64:14
   2: core::result::unwrap_failed
             at /rustc/b70baa4f922a1809d79caeaeb902800c3be283b9/library/core/src/result.rs:1790:5
   3: <tokio::time::timeout::Timeout<T> as core::future::future::Future>::poll
   4: <runtime::rpc::InterBtcParachain as runtime::rpc::SudoPallet>::sudo::{{closure}}
   5: <runtime::rpc::InterBtcParachain as runtime::rpc::SudoPallet>::set_storage::{{closure}}
   6: <runtime::rpc::InterBtcParachain as runtime::rpc::SudoPallet>::set_bitcoin_confirmations::{{closure}}
   7: runtime::integration::default_provider_client::{{closure}}
   8: faucet::http::tests::test_fund_rich_user_fails::{{closure}}
   9: tokio::runtime::park::CachedParkThread::block_on
  10: tokio::runtime::context::runtime::enter_runtime
  11: tokio::runtime::runtime::Runtime::block_on
  12: faucet::http::tests::test_fund_rich_user_fails
  13: core::ops::function::FnOnce::call_once
  14: core::ops::function::FnOnce::call_once

Code that passes out the error

let tx_progress = self
    .api
    .tx()
    .create_signed_with_nonce(&call, &self.signer, nonce, Default::default())?
    .submit_and_watch()
    .await.unwrap();

Link to code

If all the custom types are defined correctly, is there any reason for the failure, or have I missed something?

[niklasad1]

Hmm, the node regard the transaction as invalid and it's quite tricky to debug.

You are sure the ExtrinsicParams format is correct?

I guess the easiest way forward would be to create an extrinsic with the old code and the new code and compare the hash?
Not sure, if there is a mismatch between subxt and remote node but hard to say with this information sorry.

[jsdw]

@nakul1010 have you resolved this, now that your subxt upgrade is merged? I'd love to know what the issue was if so :)

[nakul1010]

@jsdw
Sorry for the late reply. After debugging through the approach suggested by @niklasad1, I found out that the
type Address = MultiAddress<Self::AccountId, ()>; config was not correctly assigned.
It should have been
type Address = Self::AccountId.
Hence, the tx was regarded as invalid.

[jsdw]

Ah interesting; I haven't come across that particular config before; I guess no other types of address are needed so it was just collapsed to AccountId :)

Thanks for letting me know; always good to learn about these sorts of things for the future!