'TranslationUnit::parse failed' on aarch64-apple-ios since Bindgen 0.31

[appaquet]

On my way trying to bump bindgen in my project from 0.26.3 to 0.32.1, found out that bindgen isn't working anymore from version 0.31 on the aarch64-apple-ios target, but is still working on other iOS and MacOS targets. I use Bindgen from a build.rs, which gets compiled for each target my project supports and fails on aarch64-apple-ios. Using the command line bindgen gives me the same result.

My setup:

• MacOS 10.13.2 with Apple LLVM 9.0.0
• Rust 1.23.0

My header:

typedef struct _foo_context foo_context;
foo_context* foo_new(char* bar);

Bindgen Invocation:

$  RUST_BACKTRACE=1 bindgen --no-layout-tests --dump-preprocessed-input test.h -- --target=aarch64-apple-ios

Actual Results:

error: unknown target triple 'unknown-apple-macosx10.4.0', please use -triple or -arch

Found out a mention that "arm64" instead of "aarch64" could be passed to clang, which apparently works:

$ RUST_BACKTRACE=1 bindgen --no-layout-tests --dump-preprocessed-input test.h -- --target=arm64-apple-ios

Gives me

/* automatically generated by rust-bindgen */

#[repr(C)]
#[derive(Debug, Copy, Clone)]
pub struct _foo_context {
    _unused: [u8; 0],
}
pub type foo_context = _foo_context;
extern "C" {
 # [ link_name = "\u{1}_foo_new" ]
    pub fn foo_new(bar: *mut ::std::os::raw::c_char) -> *mut foo_context;
}

And it also works like before on all the other architectures I use:

aarch64-linux-android
armv7-apple-ios
armv7-linux-androideabi
armv7s-apple-ios
i386-apple-ios
i686-linux-android
x86_64-apple-darwin
x86_64-apple-ios
x86_64-linux-android

Thanks !

[mfronczyk]

I have the same issue when running bindgen using API - it doesn't work when the build target is set to "aarch64-apple-ios".

let bindings = bindgen::Builder::default()
        .header("CRoaring/roaring.h")
        .generate_inline_functions(true)
        .generate()
        .expect("Unable to generate bindings");

It fails when the newest bindgen is used, but it seems to work fine at 0.30.0 version.

[emilio]

Does it work if you set -target explicitly using clang_flags?

[mfronczyk]

You mean trying to run bindgen from command line instead of from build.rs?

[emilio]

No I mean passing explicitly the target via clang_arg / clang_args.

[appaquet]

Like I said in my original bug description, passing --target aarch64-apple-ios doesn't work either.
It gives error: unknown target triple 'unknown-apple-ios5.0.0', please use -triple or -arch. But passing --target=arm64-apple-ios works.

[ghost]

I have this same issue with v0.50.0 when building via cargo lipo

rust-bindgen/src/ir/context.rs

Line 567 in 18a64e6

clang::TranslationUnit::parse(

@emilio If I detect and replace --target=aarch64-apple-ios with --target=arm64-apple-ios on this line, would it cause issues somewhere else in the code?

https://github.com/facebook/fbghc/blob/068b7e983f4a0b35f453aa5e609998efd0c3f334/utils/llvm-targets/gen-data-layout.sh#L102

This codebase does a similar thing.

[emilio]

Ugh, what a mess. Yeah, that'd work, I think.

I don't think we look at particular targets much further down the pipeline, so it should be fine if it works.

[simlay]

http://lists.llvm.org/pipermail/llvm-dev/2017-March/110993.html:

Darwin provides a limited set of named configurations rather than
using triples directly. The canonical way to compile for AArch64 there
is by specifying "-arch arm64" instead of -target.

It's still pretty 🤢if you ask me though.

Would it be reasonable to have bindgen transform the --target aarch64-apple-ios to -arch arm64? I really don't like that solution but the alternative is this really odd and hard to find bit of documentation for this one annoying edge case.

[saurik]

@simlay FWIW, I've never had issues using --target on Darwin, even though -arch is maybe more "canonical". But yeah: Apple doesn't consider their architecture to be "aarch64", and in fact I would go so far as to note that they didn't actually implement the aarch64 calling convention "to spec", and so I've always felt "arm64" is simply a different beast entirely; but like, since Rust (as well as a lot of other projects: Rust is in good company) has decided to use the name aarch64 here, you definitely should transform the name before passing it to clang.

Regardless, I will call attention to one of these patches that has referenced this issue, where a downstream project was able to mess with the arguments to bindgen to use arm64- with --target= (not needing to use -arch) and it worked. Do I need to go get other downstream projects (the one I'm working with is nettle-sys) to add a similar workaround, is there a way I can apply this workaround using RUSTFLAGS, or is the "detect --target=aarch64-apple-ios and change it --target=arm64-apple-ios" something that can get added to bindgen?

godot-rust/gdnative@b21f2ef#diff-ef40f7a2ddacebe98cfa82c6697f2598R76

[Dushistov]

@emilio

So what is final conclusion here?
I suppose every user of bindgen see this issue, when they try to compile code for iOS/arm64,
and have to fix via "aarch64-apple-ios -> arm64-apple-ios transformation".
So why not add this into bindgen, plus may be method for Builder like build_target to change triple that passes to clang part of bindgen?

And this issue not only with iOS, for example there is cargo/rustc tripple armv7-linux-androideabi,
but current compiler for Android NDK from Google have no idea about such triple it has armv7a-linux-androideabi16, and usage of such triple for clang that part of Android NDK cause predefine:

#define __ANDROID_API__ 16
#define __ANDROID__ 1

so bindgen can generate wrong code for header file when targeting android.

[emilio]

So it seems like the issue is that the clang triple and the rust triple are different. So we need to change this code to pass something like rust_to_clang_target(effective_target), with as many special cases as needed :/

[glandium]

It seems like aarch64-apple-* is arm64-apple-*.

[glandium]

It seems like aarch64-apple-* is arm64-apple-*.

Interestingly, on the command line, plain clang takes both, but Xcode clang only takes the latter.