Triage: not aware of any changes here

This feature would be very appreciated

Hi,
I'd like to re-up this issue as well. As the original poster said, iOS supports dynamic libraries since iOS 8. It would be great to have rustc support them as well.
Among other things, it is blocking cross-compilation of the Python cryptography module for iOS: pyca/cryptography#5814

Is implementing this just a matter of setting dyanmic_linking: true on the target spec, or is there more to it?

According to this PR, it seems to be, yes: #73516
(it was merged, then pulled later: #77716 )

Ok, so as a practical matter this appears to be blocked on rust-lang/cargo#4881

Any update on this? I would really like to stop using static libraries only for iOS in projects that use shared libraries on all other platforms

Any update on this issue?

As far as I can tell, this issue has been addressed with PR #95847 (closed without merging) and #88130 (closed without merging). To the best of my knowledge (based on reading issues and PR) it is still an unresolved issue.

As far as I can tell, this issue has been addressed with PR #95847 (closed without merging) and #88130 (closed without merging). To the best of my knowledge (based on reading issues and PR) it is still an unresolved issue.

I concur, the issue does appear to be fixed by PR #95847 (closed without merging) and #88130 (closed without merging) - now the real question is, how do we get this fixed upstream? I've never made my own custom, patched Rust distribution before, and that doesn't look like a very simple thing to do, and even if it was, that's the kind of work that would likely take days of trial and error until it all works perfectly and is integrated into our CI environment.

I've been blocked on this for a while, we have a growing number of Rust libraries that we build for Windows, macOS, Linux, Android and iOS in nuget packages with C# wrappers on top. As you can understand, static linking for iOS is very annoying as it means special treatment for one platform, but also the inability to easily ship libraries in packages built separately without symbol conflicts. The static libraries also don't necessarily trim unused code paths, so they're really big.

@dvc94ch what's the next move?

It would be great to get these fixes merged into the official Rust distro! :)

what's the next move?

See #95847 (comment)

What I see is an actual fix to the current issue for which a Major Change Proposal was requested, causing the author of the pull request to close it because of lack of time. I could probably re-open a new pull request with exactly the same fixes, but then I'd have to look into what that major change proposal process is, and if, like the name says, it's a major thing.

Is it really necessary? I'm not a core Rust developer, but I am very blocked on this. All the options I see right now appear fairly time consuming for something that would allow building for a platform currently hard-blocked in the code with just two boolean values. Am I seeing this as bigger than it is?

There was a quite lengthy discussion in #77716 which might provide more context.

For anybody else still hard-blocked on this, I have decided to bite the bullet and figure out how to roll my own Rust distribution and publish a prebuilt toolchain on GitHub Releases: https://github.com/awakecoding/llvm-prebuilt

The only patch required is to set "dynamic_linking: true" in compiler/rustc_target/src/spec/apple_sdk_base.rs:

My current Rust 1.64 prebuilt distribution does not include all components, but it works just fine by manually installing the patched components the official components for the matching Rust toolchain release. I didn't get a chance to get a proper distribution manifest published somewhere, so I've just scripted the downloading and installing of individual components in my GitHub Actions workflow: https://github.com/Devolutions/sspi-rs/blob/master/.github/workflows/nuget.yml

$RustupToolchains = Resolve-Path "~/.rustup/toolchains"
$ToolchainPrefix = Join-Path $RustupToolchains "prebuilt"
New-Item -ItemType Directory -Path $ToolchainPrefix | Out-Null
$DownloadPath = "/tmp/rust-download"
New-Item -ItemType Directory -Path $DownloadPath | Out-Null
Push-Location
Set-Location $DownloadPath
@(
  "rustc-1.64.0-x86_64-apple-darwin.tar.xz",
  "rustc-dev-1.64.0-x86_64-apple-darwin.tar.xz",
  "rust-dev-1.64.0-x86_64-apple-darwin.tar.xz",
  "rust-std-1.64.0-x86_64-apple-darwin.tar.xz"
) | % {
  Write-Host "Downloading $_"
  wget -q https://github.com/awakecoding/llvm-prebuilt/releases/download/v2022.2.0/$_
}
@(
  "rust-std-1.64.0-aarch64-apple-darwin.tar.xz",
  "rust-std-1.64.0-x86_64-apple-ios.tar.xz",
  "rust-std-1.64.0-aarch64-apple-ios.tar.xz"
) | % {
  Write-Host "Downloading $_"
  wget -q https://static.rust-lang.org/dist/2022-09-22/$_
}
Get-Item *.tar.xz | % {
  $FileName = $_.Name
  $DirName = $FileName -Replace ".tar.xz",""
  Write-Host "Extracting $FileName"
  tar -xf $_
  & "./${DirName}/install.sh" "--prefix=$ToolchainPrefix"
}
Pop-Location
rustup default prebuilt

I can now finally build Rust shared libraries for iOS, after years waiting for an upstream fix. I hope this can help others stuck in the same situation. I'd be glad to help with a pull request, but I don't see how much work would be required beyond the patch I'm already doing on my own distribution. As I understood it, there's a potential for file conflicts when building multiple crate types at a time? I would rather have an open issue about fixing that as a known limitation, rather than an open issue to enable shared library building.

As an alternative (if you don't mind using nightly rust), we can also specify a custom-target-spec. The current target spec for iOS can be printed out via rustc nightly -Z unstable-options --print target-spec-json --target aarch64-apple-ios. To these specs, add the flag dynamic-linking: true. I have the following saved in file aarch64-apple-ios-dynamic.json

{
  "abi-return-struct-as-int": true,
  "arch": "aarch64",
  "archive-format": "darwin",
  "bitcode-llvm-cmdline": "-triple\u0000arm64-apple-ios11.0.0\u0000-emit-obj\u0000-disable-llvm-passes\u0000-target-abi\u0000darwinpcs\u0000-Os\u0000",
  "cpu": "apple-a7",
  "dynamic-linking" : true,
  "data-layout": "e-m:o-i64:64-i128:128-n32:64-S128",
  "dll-suffix": ".dylib",
  "dwarf-version": 2,
  "eh-frame-header": false,
  "emit-debug-gdb-scripts": false,
  "executables": true,
  "features": " neon, fp-armv8, apple-a7",
  "forces-embed-bitcode": true,
  "frame-pointer": "non-leaf",
  "function-sections": false,
  "has-rpath": true,
  "is-builtin": false,
  "is-like-osx": true,
  "link-env": [
    "ZERO_AR_DATE=1"
  ],
  "link-env-remove": [
    "MACOSX_DEPLOYMENT_TARGET"
  ],
  "linker-is-gnu": false,
  "lld-flavor": "darwin",
  "llvm-target": "arm64-apple-ios9.0",
  "max-atomic-width": 128,
  "os": "ios",
  "split-debuginfo": "packed",
  "target-family": [
    "unix"
  ],
  "target-pointer-width": "64",
  "vendor": "apple"
}

A dynamic target can then be built with
cargo nightly build --release -Z build-std=core,std,alloc --target aarch64-apple-ios-dynamic.json

Similar custom specs can be built for simulator (x86 and arm).

1.65 included this PR:

• Revert "Revert "Allow dynamic linking for iOS/tvOS targets."" #100636

This should now be supported. Assuming there are no other bugs of concern: Closing!