Build fails when using non-external library

[aclysma]

I'm trying to get vulkan, rust, and SDL2 up and running on iOS. I created an empty rust project to build as a staticlib. I added a dependency for ash-molten (not using the external feature). My lib.rs has a #[no_mangle] extern "C" function which my Xcode project calls. I am largely following the steps here: https://github.com/thombles/dw2019rust/tree/master/modules

When I trigger a build, I get this error:

/Users/pmd/dev/rust/ios_test/target/aarch64-apple-ios/debug/build/ash-molten-4ea38210b25f3328/out/MoltenVK-v1.0.41/External/glslang/External/spirv-tools/tools/reduce/reduce.cpp:33:18: error: 'system' is unavailable: not available on iOS
  int res = std::system(nullptr);
                 ^
/Applications/Xcode.app/Contents/Developer/Platforms/iPhoneSimulator.platform/Developer/SDKs/iPhoneSimulator13.2.sdk/usr/include/stdlib.h:190:6: note: 'system' has been explicitly marked unavailable here
int      system(const char *) __DARWIN_ALIAS_C(system);
         ^
/Users/pmd/dev/rust/ios_test/target/aarch64-apple-ios/debug/build/ash-molten-4ea38210b25f3328/out/MoltenVK-v1.0.41/External/glslang/External/spirv-tools/tools/reduce/reduce.cpp:41:21: error: 'system' is unavailable: not available on iOS
  int status = std::system(command.c_str());
                    ^
/Applications/Xcode.app/Contents/Developer/Platforms/iPhoneSimulator.platform/Developer/SDKs/iPhoneSimulator13.2.sdk/usr/include/stdlib.h:190:6: note: 'system' has been explicitly marked unavailable here
int      system(const char *) __DARWIN_ALIAS_C(system);
         ^
2 errors generated.
make[2]: *** [tools/CMakeFiles/spirv-reduce.dir/reduce/reduce.cpp.o] Error 1
make[1]: *** [tools/CMakeFiles/spirv-reduce.dir/all] Error 2
make: *** [all] Error 2
thread 'main' panicked at 'failed to fetchDependencies', /Users/pmd/.cargo/registry/src/github.com-1ecc6299db9ec823/ash-molten-0.5.0+41/build.rs:86:9
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace

It looks like the spirv-tools are failing to build because they use std::system in the code which is not available in iOS. I'm not sure what to do here... is this code that would end up on device? Maybe this is an upstream change that recently broke this?

[repi]

We haven't tested this on iOS before, maybe MoltenVK needs to be built with some additional flags to compile properly on iOS?

[aclysma]

I looked at this a bit more. Cloning the repo and just trying to build it for macos (cargo build) is failing for me. It could be due to upstream changes, or maybe Xcode version differences. I'm not familiar enough with either one to know for sure, but I will guess Xcode versions :) I have two different machines failing the build with different errors. The one with most recent Xcode and building for macOS results in

  = note: Undefined symbols for architecture x86_64:
            "___isPlatformVersionAtLeast", referenced from:
                MVKPresentableSwapchainImage::presentCAMetalDrawable(id<MTLCommandBuffer>, bool, unsigned int, unsigned long long) in libash_molten-a83992e3e005ef0d.rlib(libMoltenVK.a-x86_64-master.o)
          ld: symbol(s) not found for architecture x86_64

Building x86_64-apple-ios (simulator) or aarch64-apple-ios results in

  = note: ld: framework not found AppKit
          clang: error: linker command failed with exit code 1 (use -v to see invocation)

Maybe iOS requires different frameworks?

Some other notes:

• There is a fetchDependencies shell script in the moltenvk repo. It looks like it's had a number of changes lately, among them being a requirement to specify what platforms to build. I'm not sure that's a factor right now though since the crate is pinned to release v.1.0.43. But this may be something that will need to be looked at in the future. KhronosGroup/MoltenVK@50828dd#diff-04c6e90faac2675aa89e2176d2eec7d8R115
  • One of the nice changes with that though is that it looks like they've added support for simulator, and support for generating "fat" libraries with both aarch64 and x86_64 binary in them.
  • Even though I didn't pick --tvos I still have build errors related to it and ended up building my own local version of MoltenVK with all to get past them
• Another thing I noticed is that on my machine with a physical device associated, I get error messages about being unable to prepare the device.
• There are also two different build paths, one for if you have ninja installed and one that doesn't require it.

I don't think any of these issues are impossible to solve, but they may require a decent amount of ongoing maintenance to keep up with upstream changes. There's also a surprising number of usage scenarios (3 rust targets, multiple device families, multiple build paths depending on what's installed) I suspect that for the time being automatically building moltenvk is going to be more fragile than building MoltenVK myself. At the least, it's easier to get feedback and troubleshoot when it building MoltenVK does fail.

[aclysma]

Oh just a heads up, "fat" libraries might not be possible to use with rust right now :/
rust-lang/rust#55235

[repi]

Ouch does sound somewhat complex, but good investigations!

Ideally we've been wanting to try out using gfx-portability instead of MoltenVK, which is a smaller and much faster to build code base (and in Rust!), but we haven't tried it out yet. Both @MaikKlein and I are also both out on vacation right now.

Could potentially be an option here instead of further deeper work on MoltenVK, but likely will have its own issues and challenges, though less likely around build systems.