Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Support dylib on iOS #21727

Open
drewcrawford opened this issue Jan 28, 2015 · 16 comments
Open

Support dylib on iOS #21727

drewcrawford opened this issue Jan 28, 2015 · 16 comments
Labels
C-enhancement Category: An issue proposing an enhancement or a PR with one. O-ios Operating system: iOS P-low Low priority T-compiler Relevant to the compiler team, which will review and decide on the PR/issue.

Comments

@drewcrawford
Copy link
Contributor

drewcrawford commented Jan 28, 2015

iOS added support for dynamic libraries in iOS 8. Clang/LLVM can now build them:

$ clang -arch armv7 -arch armv7s -isysroot /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS8.1.sdk/  -dynamiclib test.c

However rustc cannot:

$ rustc --crate-type dylib --target=armv7-apple-ios test.rs
warning: dropping unsupported crate type `CrateTypeDylib` for target `armv7-apple-ios`

We should support building dylibs on the platform.

@sanxiyn sanxiyn added the O-ios Operating system: iOS label Jan 29, 2015
@steveklabnik steveklabnik added the C-enhancement Category: An issue proposing an enhancement or a PR with one. label Nov 4, 2015
@brson brson added P-low Low priority T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. labels Apr 11, 2017
@steveklabnik
Copy link
Member

steveklabnik commented Sep 24, 2018

Triage: not aware of any changes here

@extrawurst
Copy link

extrawurst commented Jan 2, 2019

This feature would be very appreciated

@holzschu
Copy link

holzschu commented Feb 11, 2021

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

@alex
Copy link
Member

alex commented Feb 11, 2021

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

@holzschu
Copy link

holzschu commented Feb 11, 2021

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

@alex
Copy link
Member

alex commented Feb 11, 2021

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

staltz added a commit to staltz/manyverse that referenced this issue Sep 3, 2021
ssb-keys-mnemonic-neon had some transitive dependencies updated so
that it doesn't compile anymore on old versions of Rust (e.g. 1.46.0),
so this means we are forced to use new versions of Rust, but in new
versions we have issue rust-lang/rust#21727
which means that Rust and Cargo do not support cdylib, which is really
what we need on iOS. So, we're stuck, and this commit disables Rust
usage on iOS just so we can make working releases for iOS users.
@awakecoding
Copy link

awakecoding commented Feb 7, 2022

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

@TCROC
Copy link

TCROC commented Jun 21, 2022

Any update on this issue?

@holzschu
Copy link

holzschu commented Jul 13, 2022

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.

@awakecoding
Copy link

awakecoding commented Aug 16, 2022

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?

@TCROC
Copy link

TCROC commented Aug 16, 2022

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

@messense
Copy link
Contributor

messense commented Aug 16, 2022

what's the next move?

See #95847 (comment)

@awakecoding
Copy link

awakecoding commented Aug 16, 2022

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?

image

@messense
Copy link
Contributor

messense commented Aug 16, 2022

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

@awakecoding
Copy link

awakecoding commented Sep 26, 2022

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:

image

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.

@georgemp
Copy link

georgemp commented Oct 13, 2022

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).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
C-enhancement Category: An issue proposing an enhancement or a PR with one. O-ios Operating system: iOS P-low Low priority T-compiler Relevant to the compiler team, which will review and decide on the PR/issue.
Projects
None yet
Development

No branches or pull requests