Android library build error

[zoedberg]

Trying to build the android library, I've received a E0404 error on rust build. Here's the log:

./build_rust.sh 
    Updating git repository `https://github.com/LNP-BP/zeromq-src-rs`
    Updating git repository `https://github.com/afilini/rust-electrum-client.git`
    Updating crates.io index
warning: Patch `torut v0.1.3 (https://github.com/afilini/torut?branch=vendored-openssl-android#41c2dcf0)` was not used in the crate graph.
Check that the patched package version and available features are compatible
with the dependency requirements. If the patch has a different version from
what is locked in the Cargo.lock file, run `cargo update` to use the new
version. This may also occur with an optional dependency that is not enabled.
   Compiling rgb v0.1.0 (/mnt/dmc/zoe/work/rgb-node/ffi)
   Compiling rgb_node v0.1.0-beta.2 (/mnt/dmc/zoe/work/rgb-node)
^[x    Building [=====================================================> ] 324/326: rgb_node                                                                                                                                                                                                                                  error[E0404]: expected trait, found type alias `validation::TxResolver`
   --> src/stash/runtime.rs:374:6
    |
374 | impl validation::TxResolver for DummyTxResolver {
    |      ^^^^^^^^^^^^^^^^^^^^^^ type aliases cannot be used as traits
    |
    = help: you might have meant to use `#![feature(trait_alias)]` instead of a `type` alias

error[E0404]: expected trait, found type alias `TxResolver`
  --> src/stash/electrum.rs:39:6
   |
39 | impl TxResolver for &ElectrumTxResolver {
   |      ^^^^^^^^^^ type aliases cannot be used as traits
   |
   = help: you might have meant to use `#![feature(trait_alias)]` instead of a `type` alias

warning: the item `strict_encode` is imported redundantly
   --> src/cli/fungible.rs:255:13
    |
28  | use lnpbp::strict_encoding::strict_encode;
    |     ------------------------------------- the item `strict_encode` is already imported here
...
255 |         use lnpbp::strict_encoding::strict_encode;
    |             ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
    |
    = note: `#[warn(unused_imports)]` on by default

warning: the item `strict_encode` is imported redundantly
   --> src/cli/fungible.rs:288:13
    |
28  | use lnpbp::strict_encoding::strict_encode;
    |     ------------------------------------- the item `strict_encode` is already imported here
...
288 |         use lnpbp::strict_encoding::strict_encode;
    |             ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

error: aborting due to 2 previous errors; 2 warnings emitted

For more information about this error, try `rustc --explain E0404`.
error: could not compile `rgb_node`.

To learn more, run the command again with --verbose.

[dr-orlovsky]

Can you pls make sure you update to the latest version? (it compiles on mine)

@afilini was doing Electrum part, may be he can know why this strange error happens under some builds

[afilini]

I would try with cargo update or cargo clean and then re-build.

TxResolver used to be a type alias but it's now a trait. I'm assuming cargo hasn't updated some of the dependencies (probably rust-lnpbp)

[zoedberg]

I've run cargo update && cargo clean and then re-built (commit 339b9ff). The previously reported error doesn't appear anymore, but then I've received a E0277 error:

   [ ... ]
   Compiling lightning v0.0.11 (https://github.com/LNP-BP/rust-lightning?tag=lnpbp-v0.1.0-beta-4#06469874)
   Compiling electrum-client v0.2.0-beta.3 (https://github.com/LNP-BP/rust-electrum-client.git?tag=lnpbp-v0.1.0-beta-4#f0bdc38c)
   Compiling torut v0.1.5
   Compiling lnpbp v0.1.0-beta.3 (https://github.com/LNP-BP/rust-lnpbp?branch=master#3f65e6e3)
   Compiling rgb v0.1.0 (/mnt/dmc/zoe/work/rgb-node/ffi)
error[E0277]: can't compare `[u8]` with `[u8; 33]`
  --> /home/zoe/.cargo/git/checkouts/rust-lnpbp-1c6b6ac6d4fb658b/3f65e6e/src/rgb/contract/amount.rs:96:36
   |
96 |         match (&self.commitment.0).partial_cmp(&other.commitment.0) {
   |                                    ^^^^^^^^^^^ no implementation for `[u8] < [u8; 33]` and `[u8] > [u8; 33]`
   |
   = help: the trait `std::cmp::PartialOrd<[u8; 33]>` is not implemented for `[u8]`

error[E0277]: arrays only have std trait implementations for lengths 0..=32
  --> /home/zoe/.cargo/git/checkouts/rust-lnpbp-1c6b6ac6d4fb658b/3f65e6e/src/rgb/contract/amount.rs:96:48
   |
96 |         match (&self.commitment.0).partial_cmp(&other.commitment.0) {
   |                                                ^^^^^^^^^^^^^^^^^^^ the trait `std::array::LengthAtMost32` is not implemented for `[u8; 33]`
   |
   = note: required because of the requirements on the impl of `std::cmp::PartialEq<[u8; 33]>` for `[u8]`

error: aborting due to 2 previous errors

For more information about this error, try `rustc --explain E0277`.
error: could not compile `lnpbp`.

To learn more, run the command again with --verbose.
warning: build failed, waiting for other jobs to finish...
error: build failed

> Task :library:buildRust FAILED

FAILURE: Build failed with an exception.

* What went wrong:
Execution failed for task ':library:buildRust'.
> Process 'command './build_rust.sh'' finished with non-zero exit value 101

* Try:
Run with --stacktrace option to get the stack trace. Run with --info or --debug option to get more log output. Run with --scan to get full insights.

* Get more help at https://help.gradle.org

BUILD FAILED in 2m 6s
5 actionable tasks: 1 executed, 4 up-to-date

then I've run rustup update (updating rustc from 1.46.0 to 1.48.0) and re-built again: BUILD SUCCESSFUL in 10m 11s.

So this issue can be closed, but I would talk about committing the Cargo.lock file, for this project there could be a purpose; see here for possible reasons to do that. As an alternative, we should document that running cargo update may be necessary when re-building an updated version of this library.

[dr-orlovsky]

I would talk about committing the Cargo.lock file, for this project there could be a purpose

Good point

As an alternative, we should document that running cargo update may be necessary when re-building an updated version of this library.

Sounds better. @zoedberg can you pls open an issue discussion the best option?