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

Allow dynamic linking for iOS/tvOS targets #73516

Merged
merged 1 commit into from Jun 25, 2020
Merged

Allow dynamic linking for iOS/tvOS targets #73516

merged 1 commit into from Jun 25, 2020

Conversation

Absolucy
Copy link
Contributor

During the development and testing of the Crabapple project, one obstacle was the lack of cdylib target support for iOS. Surprisingly, once dynamic_linking was enabled for iOS targets, it worked seemingly flawlessly.

I could not find any information on why this was initially or still is disabled.

@rust-highfive
Copy link
Collaborator

Thanks for the pull request, and welcome! The Rust team is excited to review your changes, and you should hear from @nikomatsakis (or someone else) soon.

If any changes to this PR are deemed necessary, please add them as extra commits. This ensures that the reviewer can see what has changed since they last reviewed the code. Due to the way GitHub handles out-of-date commits, this should also make it reasonably obvious what issues have or haven't been addressed. Large or tricky changes may require several passes of review and changes.

Please see the contribution instructions for more information.

@rust-highfive rust-highfive added the S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. label Jun 19, 2020
@nikomatsakis
Copy link
Contributor

OK, cc @simlay @matthiaskrgr and @trevyn as past contributors to this file -- any thoughts?

@Absolucy
Copy link
Contributor Author

Absolucy commented Jun 22, 2020

In addition, may I ask why aarch64-apple-ios is used over arm64-apple-ios? LLVM uses arm64, apple resources use arm64, most people use arm64.

@nikomatsakis
Copy link
Contributor

nikomatsakis commented Jun 22, 2020

@Luxxxxy

Specifically, are you saying that that you are not aware of anyone who uses aarch64-apple-ios as the target triple besides Rust? Or that it is used elsewhere, but not for this purpose? Perhaps you can edit your comment to clarify. =)

@Absolucy
Copy link
Contributor Author

@nikomatsakis Alright, sorry for being unclear.

Here's some examples:

  • If I want to compile linux for ARMv8, I'll do ARCH=arm64 make
  • Clang takes arm64 in arch/target triples. For example, clang --target=arm64-apple-ios

In addition, the "official" naming for ARM architectures is very confusing. Let's look at the rustc arch names for various ARM architectures:

  • armv4t
  • armv5te
  • armv6
  • armv7
  • armv7a
  • armv7r
  • armv7s
  • aarch64

Notice how aarch64 is inconsistent with the rest. We'd call this armv8 or armv8a if we wished to be consistent.

Although I'm not sure if this thread is the proper place for discussing this, but I'm new to contributing to Rust so idk.

@trevyn
Copy link
Contributor

trevyn commented Jun 23, 2020

AArch64 is the name of the LLVM backend which targets all 64-bit ARM architectures (and indeed is the proper general name for 64-bit ARM architectures); targeting a specific architecture would be incorrect in this case. For why it is called AArch64 instead of arm64, perhaps this link provides some context: https://www.phoronix.com/scan.php?page=news_item&px=MTY5ODk

Back on topic, I don’t know the origin of the dynamic_linking setting in this file, but I do know that iOS has historically not allowed dynamic linking of user code as policy — even though it was technically possible, such binaries could not be made to pass App Store review. This may have changed, and at any rate, we certainly don’t want to limit Rust to the App Store criteria.

That said, I do not know what impact removing that line will have. @Luxxxxy, is it possible to override that setting at build time?

@Absolucy
Copy link
Contributor Author

@trevyn I'm not sure. I've been using iOS dylibs for Cydia Substrate tweaks.

@nikomatsakis
Copy link
Contributor

I'd be inclined to land the PR unless we know of a concrete problem it will cause -- after all, we do know of at least one user that is helped by the change.

@trevyn
Copy link
Contributor

trevyn commented Jun 23, 2020

Sure; I’d be happy to test against my iOS project once it lands in nightly.

@Absolucy
Copy link
Contributor Author

Yeah once this lands in nightly, Crabapple can start using it instead of the current rustc-ios-nbt build I have.

@nikomatsakis
Copy link
Contributor

@bors r+ rollup

@bors
Copy link
Contributor

bors commented Jun 24, 2020

📌 Commit 56e115a has been approved by nikomatsakis

@bors bors added S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Jun 24, 2020
@nikomatsakis
Copy link
Contributor

OK, I'm going to merge, and we'll see what happens. =)

@Absolucy
Copy link
Contributor Author

👍

Dylan-DPC-zz pushed a commit to Dylan-DPC-zz/rust that referenced this pull request Jun 25, 2020
…-linking, r=nikomatsakis

Allow dynamic linking for iOS/tvOS targets

During the development and testing of the [Crabapple project](https://github.com/Crabapple-iOS/Crabapple), one obstacle was the lack of `cdylib` target support for iOS. Surprisingly, once `dynamic_linking` was enabled for iOS targets, it worked seemingly flawlessly.

I could not find any information on why this was initially or still is disabled.
This was referenced Jun 25, 2020
bors added a commit to rust-lang-ci/rust that referenced this pull request Jun 25, 2020
Rollup of 6 pull requests

Successful merges:

 - rust-lang#72700 (`improper_ctypes_definitions` lint)
 - rust-lang#73516 (Allow dynamic linking for iOS/tvOS targets)
 - rust-lang#73616 (Liballoc minor hash import tweak)
 - rust-lang#73634 (Add UI test for issue 73592)
 - rust-lang#73688 (Document the self keyword)
 - rust-lang#73698 (Add procedure for prioritization notifications on Zulip)

Failed merges:

r? @ghost
@bors bors merged commit d6c674b into rust-lang:master Jun 25, 2020
@Absolucy Absolucy deleted the feature/apple-dynamic-linking branch June 25, 2020 16:30
netbsd-srcmastr pushed a commit to NetBSD/pkgsrc that referenced this pull request Aug 30, 2020
according to various people on tech-pkg@, there are no problems with
the Firefox build

Version 1.46.0 (2020-08-27)
==========================

Language
--------
- [`if`, `match`, and `loop` expressions can now be used in const functions.][72437]
- [Additionally you are now also able to coerce and cast to slices (`&[T]`) in
  const functions.][73862]
- [The `#[track_caller]` attribute can now be added to functions to use the
  function's caller's location information for panic messages.][72445]
- [Recursively indexing into tuples no longer needs parentheses.][71322] E.g.
  `x.0.0` over `(x.0).0`.
- [`mem::transmute` can now be used in static and constants.][72920] **Note**
  You currently can't use `mem::transmute` in constant functions.

Compiler
--------
- [You can now use the `cdylib` target on Apple iOS and tvOS platforms.][73516]
- [Enabled static "Position Independent Executables" by default
  for `x86_64-unknown-linux-musl`.][70740]

Libraries
---------
- [`mem::forget` is now a `const fn`.][73887]
- [`String` now implements `From<char>`.][73466]
- [The `leading_ones`, and `trailing_ones` methods have been stabilised for all
  integer types.][73032]
- [`vec::IntoIter<T>` now implements `AsRef<[T]>`.][72583]
- [All non-zero integer types (`NonZeroU8`) now implement `TryFrom` for their
  zero-able equivalent (e.g. `TryFrom<u8>`).][72717]
- [`&[T]` and `&mut [T]` now implement `PartialEq<Vec<T>>`.][71660]
- [`(String, u16)` now implements `ToSocketAddrs`.][73007]
- [`vec::Drain<'_, T>` now implements `AsRef<[T]>`.][72584]

Stabilized APIs
---------------
- [`Option::zip`]
- [`vec::Drain::as_slice`]

Cargo
-----
Added a number of new environment variables that are now available when
compiling your crate.

- [`CARGO_BIN_NAME` and `CARGO_CRATE_NAME`][cargo/8270] Providing the name of
  the specific binary being compiled and the name of the crate.
- [`CARGO_PKG_LICENSE`][cargo/8325] The license from the manifest of the package.
- [`CARGO_PKG_LICENSE_FILE`][cargo/8387] The path to the license file.

Compatibility Notes
-------------------
- [The target configuration option `abi_blacklist` has been renamed
  to `unsupported_abis`.][74150] The old name will still continue to work.
- [Rustc will now warn if you cast a C-like enum that implements `Drop`.][72331]
  This was previously accepted but will become a hard error in a future release.
- [Rustc will fail to compile if you have a struct with
  `#[repr(i128)]` or `#[repr(u128)]`.][74109] This representation is currently only
  allowed on `enum`s.
- [Tokens passed to `macro_rules!` are now always captured.][73293] This helps
  ensure that spans have the correct information, and may cause breakage if you
  were relying on receiving spans with dummy information.
- [The InnoSetup installer for Windows is no longer available.][72569] This was
  a legacy installer that was replaced by a MSI installer a few years ago but
  was still being built.
- [`{f32, f64}::asinh` now returns the correct values for negative numbers.][72486]
- [Rustc will no longer accept overlapping trait implementations that only
  differ in how the lifetime was bound.][72493]
- [Rustc now correctly relates the lifetime of an existential associated
  type.][71896] This fixes some edge cases where `rustc` would erroneously allow
  you to pass a shorter lifetime than expected.
- [Rustc now dynamically links to `libz` (also called `zlib`) on Linux.][74420]
  The library will need to be installed for `rustc` to work, even though we
  expect it to be already available on most systems.
- [Tests annotated with `#[should_panic]` are broken on ARMv7 while running
  under QEMU.][74820]
- [Pretty printing of some tokens in procedural macros changed.][75453] The
  exact output returned by rustc's pretty printing is an unstable
  implementation detail: we recommend any macro relying on it to switch to a
  more robust parsing system.

[75453]: rust-lang/rust#75453
[74820]: rust-lang/rust#74820
[74420]: rust-lang/rust#74420
[74109]: rust-lang/rust#74109
[74150]: rust-lang/rust#74150
[73862]: rust-lang/rust#73862
[73887]: rust-lang/rust#73887
[73466]: rust-lang/rust#73466
[73516]: rust-lang/rust#73516
[73293]: rust-lang/rust#73293
[73007]: rust-lang/rust#73007
[73032]: rust-lang/rust#73032
[72920]: rust-lang/rust#72920
[72569]: rust-lang/rust#72569
[72583]: rust-lang/rust#72583
[72584]: rust-lang/rust#72584
[72717]: rust-lang/rust#72717
[72437]: rust-lang/rust#72437
[72445]: rust-lang/rust#72445
[72486]: rust-lang/rust#72486
[72493]: rust-lang/rust#72493
[72331]: rust-lang/rust#72331
[71896]: rust-lang/rust#71896
[71660]: rust-lang/rust#71660
[71322]: rust-lang/rust#71322
[70740]: rust-lang/rust#70740
[cargo/8270]: rust-lang/cargo#8270
[cargo/8325]: rust-lang/cargo#8325
[cargo/8387]: rust-lang/cargo#8387
[`Option::zip`]: https://doc.rust-lang.org/stable/std/option/enum.Option.html#method.zip
[`vec::Drain::as_slice`]: https://doc.rust-lang.org/stable/std/vec/struct.Drain.html#method.as_slice
@khagesh
Copy link

khagesh commented Sep 3, 2020

Does this PR mean that default builds will be dynamically linked now?

@Absolucy
Copy link
Contributor Author

Absolucy commented Sep 3, 2020

Does this PR mean that default builds will be dynamically linked now?

don't think so? this just means rustc can compile dylib/cdylib crates for iOS/tvOS

netbsd-srcmastr pushed a commit to NetBSD/pkgsrc that referenced this pull request Oct 30, 2020
Pkgsrc changes:
 * Portability patches for Illumos have been intregrated upstream,
   so are no longer needed in pkgsrc.
 * Adjust one other patch, and update vendor/libc cargo checksum.

Upstream changes:

Version 1.46.0 (2020-08-27)
==========================

Language
--------
- [`if`, `match`, and `loop` expressions can now be used in const functions.]
  [72437]
- [Additionally you are now also able to coerce and cast to slices (`&[T]`) in
  const functions.][73862]
- [The `#[track_caller]` attribute can now be added to functions to use the
  function's caller's location information for panic messages.][72445]
- [Recursively indexing into tuples no longer needs parentheses.][71322] E.g.
  `x.0.0` over `(x.0).0`.
- [`mem::transmute` can now be used in static and constants.][72920] **Note**
  You currently can't use `mem::transmute` in constant functions.

Compiler
--------
- [You can now use the `cdylib` target on Apple iOS and tvOS platforms.][73516]
- [Enabled static "Position Independent Executables" by default
  for `x86_64-unknown-linux-musl`.][70740]

Libraries
---------
- [`mem::forget` is now a `const fn`.][73887]
- [`String` now implements `From<char>`.][73466]
- [The `leading_ones`, and `trailing_ones` methods have been stabilised for all
  integer types.][73032]
- [`vec::IntoIter<T>` now implements `AsRef<[T]>`.][72583]
- [All non-zero integer types (`NonZeroU8`) now implement `TryFrom` for their
  zero-able equivalent (e.g. `TryFrom<u8>`).][72717]
- [`&[T]` and `&mut [T]` now implement `PartialEq<Vec<T>>`.][71660]
- [`(String, u16)` now implements `ToSocketAddrs`.][73007]
- [`vec::Drain<'_, T>` now implements `AsRef<[T]>`.][72584]

Stabilized APIs
---------------
- [`Option::zip`]
- [`vec::Drain::as_slice`]

Cargo
-----
Added a number of new environment variables that are now available when
compiling your crate.

- [`CARGO_BIN_NAME` and `CARGO_CRATE_NAME`][cargo/8270] Providing the name of
  the specific binary being compiled and the name of the crate.
- [`CARGO_PKG_LICENSE`][cargo/8325] The license from the manifest of the
  package.
- [`CARGO_PKG_LICENSE_FILE`][cargo/8387] The path to the license file.

Compatibility Notes
-------------------
- [The target configuration option `abi_blacklist` has been renamed
  to `unsupported_abis`.][74150] The old name will still continue to work.
- [Rustc will now warn if you have a C-like enum that implements `Drop`.][72331]
  This was previously accepted but will become a hard error in a future release.
- [Rustc will fail to compile if you have a struct with
  `#[repr(i128)]` or `#[repr(u128)]`.][74109] This representation is currently
  only allowed on `enum`s.
- [Tokens passed to `macro_rules!` are now always captured.][73293] This helps
  ensure that spans have the correct information, and may cause breakage if you
  were relying on receiving spans with dummy information.
- [The InnoSetup installer for Windows is no longer available.][72569] This was
  a legacy installer that was replaced by a MSI installer a few years ago but
  was still being built.
- [`{f32, f64}::asinh` now returns the correct values for negative numbers.]
  [72486]
- [Rustc will no longer accept overlapping trait implementations that only
  differ in how the lifetime was bound.][72493]
- [Rustc now correctly relates the lifetime of an existential associated
  type.][71896] This fixes some edge cases where `rustc` would erroneously
  allow you to pass a shorter lifetime than expected.
- [Rustc now dynamically links to `libz` (also called `zlib`) on Linux.][74420]
  The library will need to be installed for `rustc` to work, even though we
  expect it to be already available on most systems.
- [Tests annotated with `#[should_panic]` are broken on ARMv7 while running
  under QEMU.][74820]
- [Pretty printing of some tokens in procedural macros changed.][75453] The
  exact output returned by rustc's pretty printing is an unstable
  implementation detail: we recommend any macro relying on it to switch to a
  more robust parsing system.

[75453]: rust-lang/rust#75453
[74820]: rust-lang/rust#74820
[74420]: rust-lang/rust#74420
[74109]: rust-lang/rust#74109
[74150]: rust-lang/rust#74150
[73862]: rust-lang/rust#73862
[73887]: rust-lang/rust#73887
[73466]: rust-lang/rust#73466
[73516]: rust-lang/rust#73516
[73293]: rust-lang/rust#73293
[73007]: rust-lang/rust#73007
[73032]: rust-lang/rust#73032
[72920]: rust-lang/rust#72920
[72569]: rust-lang/rust#72569
[72583]: rust-lang/rust#72583
[72584]: rust-lang/rust#72584
[72717]: rust-lang/rust#72717
[72437]: rust-lang/rust#72437
[72445]: rust-lang/rust#72445
[72486]: rust-lang/rust#72486
[72493]: rust-lang/rust#72493
[72331]: rust-lang/rust#72331
[71896]: rust-lang/rust#71896
[71660]: rust-lang/rust#71660
[71322]: rust-lang/rust#71322
[70740]: rust-lang/rust#70740
[cargo/8270]: rust-lang/cargo#8270
[cargo/8325]: rust-lang/cargo#8325
[cargo/8387]: rust-lang/cargo#8387
[`Option::zip`]: https://doc.rust-lang.org/stable/std/option/enum.Option.html#method.zip
[`vec::Drain::as_slice`]: https://doc.rust-lang.org/stable/std/vec/struct.Drain.html#method.as_slice
@vimmerru
Copy link

@aspenluxxxy This PR added a lot of headache for iOS builds. cdylib target is near impossible to build if you are using any crate with native dependencies (ex. openssl, libsodium, zmq). You can't just find .so files for all architectures to perform correct linking. Usual workflow is the following:

  1. You build staticlib and rely that native dependencies will be linked as frameworks later
  2. You setup right cocoapods in ObjectiveC/Swift wrapper.

As cargo doesn't support platform-dependent crate types rust-lang/cargo#4881 as a result a lot of projects now broken on Rust 1.46

@trevyn
Copy link
Contributor

trevyn commented Nov 24, 2020

@vimmerru Did this PR in any way inhibit your ability to build a staticlib? This should almost always be the only way you ever need to build an iOS project; the cdylib target is only for very unique use-cases (such as Cydia tweaks, apparently), and you shouldn’t normally need to touch it.

@vimmerru
Copy link

@trevyn

Did this PR in any way inhibit your ability to build a staticlib?

Yes. It affects all cross-platform crates that require cdylib for desktop target. There is no way to skip crate type for specific platform in Cargo.toml. Builds that worked before now require at least additional flags. For example, i spend one day to understand what is broken in CI/CD for this project https://github.com/hyperledger/indy-sdk

@Absolucy
Copy link
Contributor Author

Absolucy commented Nov 24, 2020

@vimmerru That is a problem with cargo, not the aarch64-apple-ios target

@vimmerru
Copy link

vimmerru commented Nov 24, 2020

@aspenluxxxy The problem is a lot of projects can't build for iOS now due broken tooling, but value of cdlyb for iOS is small as it is useful only for few Cydia-style hackers.

Partially it is the issue in cargo, but there is no easy fix for projects that require iOS builds. As i can see this PR is already reverted in nightly due a lot of complains.

@holzschu holzschu mentioned this pull request Feb 11, 2021
@Diatrus
Copy link

Diatrus commented May 28, 2021

@aspenluxxxy The problem is a lot of projects can't build for iOS now due broken tooling, but value of cdlyb for iOS is small as it is useful only for few Cydia-style hackers.

I'm late to this, but I'm not entirely sure why you think dynamic libraries are useless excepting "Cydia-style hackers" when they have worked in stock since iOS 8.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
O-ios Operating system: iOS S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

9 participants