linker error on iOS
- Dominant language
- Rust
- Stars
- 48.2k
- Forks
- 4.8k
- Avg merge
- 3d 16h
- Merged PRs (30d)
- 171
Description
## 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
Contributor guide
Research direction
Start with the mobile example, its shell script, and the dependency path through bevy_pkv and redb; compare the Xcode-triggered build with `cargo rustc --crate-type staticlib --lib --target aarch64-apple-ios`. Trace why the Xcode build links the macOS libiconv SDK, then verify that the mobile build completes through Xcode without the linker error.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- ios, rust
- Domain
- build-system, mobile-dev
- Issue type
- Bug
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Stale
- Clarity
- Mostly clear
- Newbie friendliness
- 35/100