Cross compilation to iOS simulator requires a special flag "out of the box"

[alexcrichton]

Currently, for example, the libc crate passes a special flag to the linker, specifically the -mios-simulator-version-min flag. Note that our build system does the same thing.

cc @vhbit, would it be reasonable for rustc to just pass this flag by default? I'm not sure what the version represents, but it'd be awesome to get this "just working" out of the box!

[alexcrichton]

Sample errors: https://travis-ci.org/danburkert/memmap-rs/jobs/89613721

     Running `./custom-rustc.sh /Users/travis/.cargo/registry/src/github.lhy31512.workers.dev-0a35038f75765ae4/kernel32-sys-0.1.4/build.rs --crate-name build_script_build --crate-type bin -g --out-dir /Users/travis/build/danburkert/memmap-rs/target/debug/build/kernel32-sys-62844336d3806e02 --emit=dep-info,link -L dependency=/Users/travis/build/danburkert/memmap-rs/target/debug/deps -L dependency=/Users/travis/build/danburkert/memmap-rs/target/debug/deps --extern build=/Users/travis/build/danburkert/memmap-rs/target/debug/deps/libbuild-304afb6bdff23d72.rlib --cap-lints allow`

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

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

note: "cc" "-m64" "-L" "/Users/travis/rust/lib/rustlib/x86_64-apple-darwin/lib" "/Users/travis/build/danburkert/memmap-rs/target/debug/build/advapi32-sys-cfef7a1f30f1e5f6/build_script_build.0.o" "-o" "/Users/travis/build/danburkert/memmap-rs/target/debug/build/advapi32-sys-cfef7a1f30f1e5f6/build_script_build" "-Wl,-dead_strip" "-nodefaultlibs" "/Users/travis/build/danburkert/memmap-rs/target/debug/deps/libbuild-304afb6bdff23d72.rlib" "/Users/travis/rust/lib/rustlib/x86_64-apple-darwin/lib/libstd-35017696.rlib" "/Users/travis/rust/lib/rustlib/x86_64-apple-darwin/lib/libcollections-35017696.rlib" "/Users/travis/rust/lib/rustlib/x86_64-apple-darwin/lib/librustc_unicode-35017696.rlib" "/Users/travis/rust/lib/rustlib/x86_64-apple-darwin/lib/librand-35017696.rlib" "/Users/travis/rust/lib/rustlib/x86_64-apple-darwin/lib/liballoc-35017696.rlib" "/Users/travis/rust/lib/note: "cc" "-m64" "-L" "/Users/travis/rust/lib/rustlib/x86_64-apple-darwin/lib" "/Users/travis/build/danburkert/memmap-rs/target/debug/build/kernel32-sys-62844336d3806e02/build_script_build.0.o" "-o" "/Users/travis/build/danburkert/memmap-rs/target/debug/build/kernel32-sys-62844336d3806e02/build_script_build" "-Wl,-dead_strip" "-nodefaultlibs" "/Users/travis/build/danburkert/memmap-rs/target/debug/deps/libbuild-304afb6bdff23d72.rlib" "/Users/travis/rust/lib/rustlib/x86_64-apple-darwin/lib/libstd-35017696.rlib" "/Users/travis/rust/lib/rustlib/x86_64-apple-darwin/lib/libcollections-35017696.rlib" "/Users/travis/rust/lib/rustlib/x86_64-apple-darwin/lib/librustc_unicode-35017696.rlib" "/Users/travis/rust/lib/rustlib/x86_64-apple-darwin/lib/librand-35017696.rlib" "/Users/travis/rust/lib/rustlib/x86_64-apple-darwin/lib/liballoc-35017696.rlib" "/Users/travis/rust/lib/rustlib/x86_64-apple-darwin/lirb/liballoc_jemalloc-35017696.rlib" "/Users/travis/rust/lib/rustlib/x86_64-apple-darwin/lib/liblibc-35017696.rlib" "/Users/travis/rust/lib/rustlib/x86_64-apple-darwin/lib/libcore-35017696.rlib" "-L" "/Users/travis/build/danburkert/memmap-rs/target/debug/deps" "-L" "/Users/travis/build/danburkert/memmap-rs/target/debug/deps" "-L" "/Users/travis/rust/lib/rustlib/x86_64-apple-darwin/lib" "-L" "/Users/travis/build/danburkert/memmap-rs/.rust/lib/x86_64-apple-darwin" "-L" "/Users/travis/build/danburkert/memmap-rs/lib/x86_64-apple-darwin" "-l" "System" "-l" "pthread" "-l" "c" "-l" "m" "-mios-simulator-version-min=7.0" "-l" "compiler-rt"

note: ld: warning: directory not found for option '-L/Users/travis/build/danburkert/memmap-rs/.rust/lib/x86_64-apple-darwin'

ld: warning: dustlib/x86_64-apple-darwin/lib/liballoc_jemalloc-35017696.rlib" "/Users/travis/rust/lib/rustlib/x86_64-apple-darwin/lib/liblibc-35017696.rlib" "/Users/travis/rust/lib/rustlib/x86_64-apirectory not found for option '-L/Users/travis/build/danburkert/memmap-rs/lib/x86_64-apple-darwin'

ld: building for iOS Simulator, but linking against dylib built for MacOSX file '/usr/lib/libSystem.dylib' for architecture x86_64

clang: error: linker command failed with exit code 1 (use -v to see invocation)

error: aborting due to previous error

ple-darwin/lib/libcore-35017696.rlib" "-L" "/Users/travis/build/danburkert/memmap-rs/target/debug/deps" "-L" "/Users/travis/build/danburkert/memmap-rs/target/debug/deps" "-L" "/Users/travis/rust/lib/rustlib/x86_64-apple-darwin/lib" "-L" "/Users/travis/build/danburkert/memmap-rs/.rust/lib/x86_64-apple-darwin" "-L" "/Users/travis/build/danburkert/memmap-rs/lib/x86_64-apple-darwin" "-l" "System" "-l" "pthread" "-l" "c" "-l" "m" "-mBuild failed, waiting for other jobs to finish...

ios-simulator-version-min=7.0" "-l" "compiler-rt"

note: ld: warning: directory not found for option '-L/Users/travis/build/danburkert/memmap-rs/.rust/lib/x86_64-apple-darwin'

ld: warning: directory not found for option '-L/Users/travis/build/danburkert/memmap-rs/lib/x86_64-apple-darwin'

ld: building for iOS Simulator, but linking against dylib built for MacOSX file '/usr/lib/libSystem.dylib' for architecture x86_64

clang: error: linker command failed with exit code 1 (use -v to see invocation)

error: aborting due to previous error

Could not compile `kernel32-sys`.

Caused by:

  Process didn't exit successfully: `./custom-rustc.sh /Users/travis/.cargo/registry/src/github.lhy31512.workers.dev-0a35038f75765ae4/kernel32-sys-0.1.4/build.rs --crate-name build_script_build --crate-type bin -g --out-dir /Users/travis/build/danburkert/memmap-rs/target/debug/build/kernel32-sys-62844336d3806e02 --emit=dep-info,link -L dependency=/Users/travis/build/danburkert/memmap-rs/target/debug/deps -L dependency=/Users/travis/build/danburkert/memmap-rs/target/debug/deps --extern build=/Users/travis/build/danburkert/memmap-rs/target/debug/deps/libbuild-304afb6bdff23d72.rlib --cap-lints allow` (exit code: 101)

[vhbit]

@alexcrichton

• version is minimum iOS version, i.e. 7.0 means it'll run on iOS 7+. For Rust stdlib it's safe to pass 7.0 as it uses almost none of Objective C APIs. And that should be true for most of crates.
• I believe linkage fails only for bin targets. Since there is no way to run bare binary on Simulator (and on device without jailbreak) anyway maybe a quicker workaround is to disable bin targets at all for iOS.

[danburkert]

Interesting, I wasn't aware that rust binaries can't run on ios. What is the libc test doing, then? I guess the best I can do for memmap in light of this is to just make sure it compiles.

[alexcrichton]

Hm yeah so for the i386/x86_64 iOS targets I do believe that generating a binary is possible (it's what liblibc is doing). In that sense it seems preferable to not forbid it?

I'm mostly curious as well if we can

A) not require passing this flag
B) find an appropriate value for the compiler to pass automatically.

[vhbit]

@danburkert,

I wasn't aware that rust binaries can't run on ios

I'd reframe it a bit: there is no easy way to run binaries on simulator and/or on non-jailbroken device. It's
not related to Rust at all and while technically binary is completely valid nobody can actually use it.

See below.

@alexcrichton

Hm yeah so for the i386/x86_64 iOS targets I do believe that generating a binary is possible

Yep, it's possible, but you can't use it anyway without a bit of manual interaction.

As far as I understood from logs this error happens during linking "build" script. Let's consider it succeeds - cargo still can't use it anyway as it doesn't know how to run that build script neither on jailbroken device nor simulator, so yep, the error will just move one step further - it'll fail on executing it, isn't it?

So the proper "workaround" is to disable building build script (sorry for tautology) at all, for example like this (in .cargo/config:

[target.i386-apple-ios.advapi32-sys]
rustc-flags = ""

And maybe similar patches (for all ios targets) will be required for other win32 related crates which use build scripts.

[alexcrichton]

Yep, it's possible, but you can't use it anyway without a bit of manual interaction.

Could you clarify this? For the libc tests, we just run the binary that was generated (e.g. ./foo) and it seems to be working just fine?

The relevant link error here is not for build script as those are always compiled for the host (although the logs here may have more errors) but rather for the binary itself (e.g. what's built from cargo build).

[vhbit]

@alexcrichton,

Could you clarify this? For the libc tests, we just run the binary that was generated (e.g. ./foo) and it seems to be working just fine?

To be honest - it was a surprise for me, I believe it wasn't possible before or I didn't try hard enough earlier.

I've created a test C app, tried to run - and failed. The primary reason was that it seems Xcode used to link against UIKit framework even though build logs haven't mentioned it at all. After a bit of wrangling I got rid of that dependency and after that was able to run app from terminal.

Still is that even after linking to simulator libraries, here is the output of runing otool -L sim-bin:

sim-bin:
    /System/Library/Frameworks/Foundation.framework/Foundation (compatibility version 300.0.0, current version 1241.14.0)
    /usr/lib/libobjc.A.dylib (compatibility version 1.0.0, current version 228.0.0)
    /usr/lib/libSystem.dylib (compatibility version 1.0.0, current version 1226.10.1)

As a resume - yep, I was wrong, it is possible to run a binary if it doesn't link any UI-related frameworks. The question remains is if host system libraries (as I believe they'll be used without applying any magic) are functionally equal to simulator ones (quick check - binaries differ). They should, but there is still a room for an unexpected surprise.

The relevant link error here is not for build script as those are always compiled for the host

Hmm, log clearly says that it is build script or I'm looking to a wrong log:

Caused by:
  Process didn't exit successfully: `./custom-rustc.sh /Users/travis/.cargo/registry/src/github.lhy31512.workers.dev-0a35038f75765ae4/kernel32-sys-0.1.4/build.rs 
--crate-name build_script_build --crate-type bin -g --out-dir /Users/travis/build/danburkert/memmap-rs/target/debug/build/kernel32-sys-62844336d3806e02 
--emit=dep-info,link -L dependency=/Users/travis/build/danburkert/memmap-rs/target/debug/deps 
-L dependency=/Users/travis/build/danburkert/memmap-rs/target/debug/deps 
--extern build=/Users/travis/build/danburkert/memmap-rs/target/debug/deps/libbuild-304afb6bdff23d72.rlib --cap-lints allow` (exit code: 101)

[alexcrichton]

If this isn't really supposed to work or only works by accident then I'm fine closing this out, it sounds like at the very least this is super non-standard!

Ah and by not for the build script I meant moreso that the travis logs linked here erroneously compiled the build script with the extra flags when in fact it should only have been passed to the final binary.

[steveklabnik]

triage: libc still passing this flag today

[azolotko]

Just to clarify, what's blocking this issue? What kind of decision needs to be made and by whom? Asking because a similar -mios-version-min=7.0.0 flag needs to be passed to cross-compile to the armv7-apple-ios target. Otherwise, one gets the following error from the linker:

ld: library not found for -lcrt1.3.1.o

This damages the out-of-box experience for cross-compilation users.

Thanks.

[madsmtm]

Triage: libc is no longer passing the flag as of rust-lang/libc#1112, since they removed support for iOS Simulator in their CI.

It could probably be re-added though, rustc nowadays passes the full target to LLVM including the deployment target and passes the correct platform version to the linker, so I believe this issue can now be closed.