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

aarch64-apple-ios-sim: unrecognized command line option ‘-arch arm64’ #711

Closed
smaryus opened this issue Aug 2, 2022 · 8 comments
Closed

Comments

@smaryus
Copy link

smaryus commented Aug 2, 2022

When I try to compile on M1 for iOS Simulator:

build()
.file(&path)
.flag("-Werror")
.compile("name");

it finishes with the following error:

running: "clang" "-O3" "-fPIC" "--target=arm64-apple-ios7.0-simulator" "-arch arm64" "-mios-simulator-version-min=7.0" "-isysroot" "/Applications/Xcode.app/Contents/Developer/Platforms/iPhoneSimulator.platform/Developer/SDKs/iPhoneSimulator15.5.sdk" "-fembed-bitcode" "-Wall" "-Wextra" "-Werror" "-o" "output_file.o" "-c" "some_c_file.c"

cargo:warning=clang: error: argument unused during compilation: '-arch arm64' [-Werror,-Wunused-command-line-argument]
exit status: 1

The problem might be related to this (lib.rs):

        } else if is_sim {
            match arch {
                "arm64" | "aarch64" => ArchSpec::Simulator("-arch arm64"),
                _ => {
                    return Err(Error::new(
                        ErrorKind::ArchitectureInvalid,
                        "Unknown architecture for iOS simulator target.",
                    ));
                }
            }
        }

that arm64 is always added.

@paxbun
Copy link

paxbun commented Jun 11, 2023

I have the same error. I'm surprised that this issue remained open for about a year.

@paxbun
Copy link

paxbun commented Jun 11, 2023

Seems like this is because clang recognizes "-arch arm64" as one argument without any value, clang-16 works well with "-arch" "arm64", but not with "-arch arm64".

@paxbun
Copy link

paxbun commented Jun 11, 2023

Oh, this is already fixed: #759

Changing the version of cc in Cargo.lock to "1.0.79" resolved the issue.

@CodingMarkus
Copy link

CodingMarkus commented Feb 13, 2024

Changing the version of cc in Cargo.lock to "1.0.79" resolved the issue.

I cannot confirm that. The current stable release (1.76) is pinned to 1.0.79 and I still have that issue. I even tried building with 1.78.0-nightly and it also has this issue.

According to the issue you've linked, it has been fixed in cc 1.0.83.

@paxbun
Copy link

paxbun commented Feb 13, 2024

@CodingMarkus You're right, I also don't get why I thought it was already fixed, but I upgraded cc from 1.0.77 to 1.0.79 and it worked. Maybe my problem was fixed thanks to the changes between those versions?

image

I rechecked the release changelog, and it is in 1.0.79, was the issue reopened when working on 1.0.83?

LeoComandini added a commit to Blockstream/gdk that referenced this issue Mar 7, 2024
See rust-lang/cc-rs#711

Co-authored-by: Luca Vaccaro <[email protected]>
@CodingMarkus
Copy link

The issue persists and I don't understand why. It should have been fixed in cc 1.0.79 and the the current stable release is pinned to 1.0.97, which is way newer, so the issue should be fixed and I still get exactly the very same issue with rustc 1.80.1

@CodingMarkus
Copy link

Ah, nevermind. It actually is fixed if you make sure that your code builds with the right installation of Rust 😉

I guess this issue can be closed by now.

@NobodyXu
Copy link
Collaborator

Thanks for confirmation!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants