Open tbraun96 opened 3 years ago
that's really weird behavior, what version of cargo make do you use? could you please try with a clean local clone and try running cargo make android
and if it worked, try the cargo make ios
? I don't have a macOS machine right now, but I used to cargo make android
and it works properly (also in the CI).
I see in these error messages a warning about Colliding filename
here:
warning: output filename collision. The lib target
scrap-ffi
in packagescrap-ffi v0.1.0 (/Users/nologik/satori.net/flutterust/native/scrap-ffi)
has the same output filename as the lib targetscrap-ffi
in packagescrap-ffi v0.1.0 (/Users/nologik/satori.net/flutterust/native/scrap-ffi)
. Colliding filename is: /Users/nologik/satori.net/flutterust/target/aarch64-linux-android/debug/deps/libscrap_ffi.a The targets should have unique names. Consider changing their names to be unique or compiling them separately.
Could you try with a clean clone and for example try only one target? ios
or android
?
Hi @shekohex,
You brought up a good point that maybe one of my build dependencies was out of date. I was using cargo-ndk 1.0. I upgraded it to that latest version, and upgraded to the most recent Makefile.toml
in this repo. I checked to see if this fixed the problem. I compiled the program using cargo make
, then tried cargo make
again to see if the same error would occur (remember: error occurs when i don't run cargo make clean
before running cargo make
). Strangely, the compiling works fine on Android, but, once it gets to compiling the targets for ios via lipo:
[INFO cargo_lipo::meta] Will build universal library for ["scrap-ffi"]
[INFO cargo_lipo::lipo] Building "scrap-ffi" for "aarch64-apple-ios"
warning: output filename collision.
The lib target `scrap_ffi` in package `scrap-ffi v0.1.0 (/Users/nologik/satori.net/flutterust/native/scrap-ffi)` has the same output filename as the lib target `scrap_ffi` in package `scrap-ffi v0.1.0 (/Users/nologik/satori.net/flutterust/native/scrap-ffi)`.
Colliding filename is: /Users/nologik/satori.net/flutterust/target/aarch64-apple-ios/debug/deps/libscrap_ffi-01ed18e308d8ab79.a
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 lib target `scrap_ffi` in package `scrap-ffi v0.1.0 (/Users/nologik/satori.net/flutterust/native/scrap-ffi)` has the same output filename as the lib target `scrap_ffi` in package `scrap-ffi v0.1.0 (/Users/nologik/satori.net/flutterust/native/scrap-ffi)`.
Colliding filename is: /Users/nologik/satori.net/flutterust/target/aarch64-apple-ios/debug/libscrap_ffi.a
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 lib target `scrap_ffi` in package `scrap-ffi v0.1.0 (/Users/nologik/satori.net/flutterust/native/scrap-ffi)` has the same output filename as the lib target `scrap_ffi` in package `scrap-ffi v0.1.0 (/Users/nologik/satori.net/flutterust/native/scrap-ffi)`.
Colliding filename is: /Users/nologik/satori.net/flutterust/target/aarch64-apple-ios/debug/deps/libscrap_ffi-01ed18e308d8ab79.a
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 lib target `scrap_ffi` in package `scrap-ffi v0.1.0 (/Users/nologik/satori.net/flutterust/native/scrap-ffi)` has the same output filename as the lib target `scrap_ffi` in package `scrap-ffi v0.1.0 (/Users/nologik/satori.net/flutterust/native/scrap-ffi)`.
Colliding filename is: /Users/nologik/satori.net/flutterust/target/aarch64-apple-ios/debug/libscrap_ffi.a
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>.
thread 'main' panicked at 'assertion failed: mtimes.insert(output.clone(), mtime).is_none()', src/tools/cargo/src/cargo/core/compiler/fingerprint.rs:996:13
stack backtrace:
0: 0x10100a1d4 - <std::sys_common::backtrace::_print::DisplayBacktrace as core::fmt::Display>::fmt::hb0278541eabdb65b
1: 0x101029cdc - core::fmt::write::h6eab26c41e1615a6
2: 0x1010026b0 - std::io::Write::write_fmt::h53012594e7e61aa3
3: 0x10100ca70 - std::panicking::default_hook::{{closure}}::h3d38db2d154383b2
4: 0x10100c598 - std::panicking::default_hook::hb9d33e9315d46c05
5: 0x10100d024 - std::panicking::rust_panic_with_hook::hcf65477e7471a4ca
6: 0x10100cbd8 - std::panicking::begin_panic_handler::{{closure}}::h98a6978c37ed787f
7: 0x10100a68c - std::sys_common::backtrace::__rust_end_short_backtrace::h989ccc6ff53356f4
8: 0x10100cb68 - _rust_begin_unwind
9: 0x10107d894 - core::panicking::panic_fmt::h72cacefe63e11063
10: 0x10107d820 - core::panicking::panic::h0416c1ef77139eda
11: 0x100b173c4 - cargo::core::compiler::fingerprint::calculate::ha7ebd2e8d5375aa7
12: 0x100b11bec - cargo::core::compiler::fingerprint::prepare_target::h9e061c15f1b23525
13: 0x100c66b5c - cargo::core::compiler::compile::h8e1a5b2363291b32
14: 0x1009edb5c - cargo::core::compiler::context::Context::compile::hf9bb50277194baa7
15: 0x100bcc468 - cargo::ops::cargo_compile::compile_ws::h9ba552f8d250f9be
16: 0x100bcc1e0 - cargo::ops::cargo_compile::compile::h169304b304473a16
17: 0x100954404 - cargo::commands::build::exec::h99c42455ffd71d1e
18: 0x10096a340 - cargo::cli::main::h109414b41770b785
19: 0x10096394c - cargo::main::hb4945485930fa182
20: 0x10095ce00 - std::sys_common::backtrace::__rust_begin_short_backtrace::h31ccbcc83be8cd7a
21: 0x10095cfcc - std::rt::lang_start::{{closure}}::h2b1de5896d1ddb85
22: 0x10100d46c - std::rt::lang_start_internal::hfcf8d8a4320307b0
23: 0x1009657a4 - _main
[ERROR cargo_lipo] Failed to build "scrap-ffi" for "aarch64-apple-ios": Executing "/Users/nologik/.rustup/toolchains/nightly-aarch64-apple-darwin/bin/cargo" "--color" "auto" "build" "-p" "scrap-ffi" "--target" "aarch64-apple-ios" "--lib" finished with error status: exit code: 101
[cargo-make][1] ERROR - Error while executing command, exit code: 1
[cargo-make][1] WARN - Build Failed.
[cargo-make] ERROR - Error while executing command, exit code: 1
[cargo-make] WARN - Build Failed.
Reguardless, I wanted to do what you recommended me to try. When I do a fresh git clone
of flutterust
, then run cargo make
, android compiles fine, but ios returns an error:
Finished dev [unoptimized + debuginfo] target(s) in 0.61s
[INFO cargo_lipo::lipo] Creating universal library for scrap-ffi
fatal error: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/lipo: archive member /Users/nologik/tmp/flutterust/target/x86_64-apple-ios/debug/libscrap_ffi.a(aesni-x86_64-macosx.o) cputype (16777228) and cpusubtype (0) does not match previous archive members cputype (16777223) and cpusubtype (3) (all members must match)
[ERROR cargo_lipo] Executing "lipo" "-create" "-output" "/Users/nologik/tmp/flutterust/target/universal/debug/libscrap_ffi.a" "/Users/nologik/tmp/flutterust/target/aarch64-apple-ios/debug/libscrap_ffi.a" "/Users/nologik/tmp/flutterust/target/x86_64-apple-ios/debug/libscrap_ffi.a" finished with error status: exit code: 1
[cargo-make][1] ERROR - Error while executing command, exit code: 1
[cargo-make][1] WARN - Build Failed.
[cargo-make] ERROR - Error while executing command, exit code: 1
[cargo-make] WARN - Build Failed.
Finally, it appears that cargo automatically selects the appropriate lib type, so, there may be no need for having crate-type = ["rlib"]
, and instead, using crate-type = ["staticlib", "cdylib", "rlib"]
. This would mean that the Makefile.toml
no longer needs the restore-crate-type
(and its counterpart) subroutine (as evidenced by cargo's output here:
[INFO cargo_lipo::lipo] Building "scrap-ffi" for "x86_64-apple-ios"
Compiling scrap-ffi v0.1.0 (/Users/nologik/tmp/flutterust/native/scrap-ffi)
warning: dropping unsupported crate type `cdylib` for target `x86_64-apple-ios`
warning: 1 warning emitted
)
That's a progress, I guess you will also need to update cargo-lipo version too.
and besides these warnings, the script that restore the crate type is used to make/force android side to only compile a shared library, not a static one.
and the other way around in iOS, since in Android or at least in flutter, we really don't need the static library, so that cuts the compile time for Android a lot!
It appears the trick is just to selectively compile targets instead of just running cargo make
to save time.
For the record, cargo-lipo
is also the latest version, so maybe there's just extra friction when dealing with a mac host (apple silicon)
oh, you on the new apple m1 chips, okay feel free to keep this open, and it would be very helpful if you got time to write this up, so it could help others. (also feel free to open a PR to the README, I'll Happily accept and merge them).
Thanks!
Hey. did you figure out how to resolve the issue with lipo and Mac ARM CPU ?
Unfortunately, in order to compile the rust program using
cargo make
, I must first runcargo make clean
. This, of course, adds a long compile-time overhead. This is the error message I get when trying tocargo make
without cleaning first:Additionally, between every compile, I need to manually change the cargo.toml. Before compile,
crate-type
must have bothcdylib
andstaticlib
in order to compile:After running
cargo make
, it gets changed to:If I forget to change the crate-type back to including
cdylib
, then compiling failsNote, as long as I complete the workarounds, the program compiles fine. It's just that there's additional compile-time overhead in having to clean the workspace and resetting the cargo.toml manually each time