linker error on iOS

[extrawurst]

Bevy version

bevy = "0.13.0"

System information

cargo 1.76.0 (c84b36747 2024-01-18)
/Applications/Xcode.app/Contents/Developer/usr/bin/xcodebuild --version
2024-03-15 12:36:31.715 xcodebuild[60660:2660219]

What you did

I added bevy_pkv as a dependency to the mobile example which as a default uses redb as a backend.

What went wrong

building via xcode leads to linker errors:

.... "-o" "[...]/target/aarch64-apple-ios/debug/deps/libredb-d5d45224ce42ca57.dylib" "-Wl,-dead_strip" "-dynamiclib" "-Wl,-dylib" "-nodefaultlibs"
  = note: ld: building for 'iOS', but linking in dylib (/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/usr/lib/libiconv.2.tbd) built for 'macOS macCatalyst zippered(macOS/Catalyst)'
          clang: error: linker command failed with exit code 1 (use -v to see invocation)


error: could not compile `redb` (lib) due to 1 previous error

Additional information

strangely enough if I build the mobile lib manually first, xcode builds fine:

cargo rustc --crate-type staticlib --lib --target aarch64-apple-ios

I tried reducing the differences of this manual build and what our shell-script does when called by xcode but I cannot get it to work. it feels like some magical config happens outside of my visibility altering how the lib gets build when run manually compared to what xcode does via our shell-script

[extrawurst]

other people encountered the problem before and thought its related to bevy_pkv: johanhelsing/bevy_pkv#43

[madsmtm]

As has been said, the issue is indeed Bevy's build_rust_deps.sh that uses LIBRARY_PATH to put the macOS SDK into the linker's search path (same as -L option). Combined with the following lines:

https://github.com/cberner/redb/blob/8a611be11d8133561525b9f9d4a41c3a5cdebfb7/src/tree_store/page_store/file_backend/unix.rs#L37

https://github.com/cberner/redb/blob/8a611be11d8133561525b9f9d4a41c3a5cdebfb7/src/tree_store/page_store/file_backend/unix.rs#L93

And the fact that redb specifies that it wants to be compiled as a dynamic library as well:

https://github.com/cberner/redb/blob/8a611be11d8133561525b9f9d4a41c3a5cdebfb7/Cargo.toml#L15

Results in Cargo attempting to build and link a dynamic library, and then the use of flock ends up trying to reference the macOS SDK.

---

I plan to fix this in rustc by being smarter about the SDK root, so that Bevy doesn't have to do the -L override, but it's gonna take some time, see rust-lang/rust#129432 for some more details.

A workaround in the meantime would be to remove the crate-type = ["cdylib", "rlib"] line from redb (and possibly submit a PR to remove that, not sure why they have it? Maybe to make the Python wrapper work?).