Allow iOS dynamic linking

[Torrekie]

This reverts PR #77716.
Since Apple LLVM actually supported compiling .dylibs on/to iOS targets, there is no reason to prevent dynamic linking on a platform that supports it.
aarch64-apple-ios as a Tier 2 target that was 'promised to be compiled', should be allowed to access such a basic feature. Once dynamic library are prohibited to be built, some common libraries such as Cryptography would no longer able to run on iOS targets, it is theoretically feasible though.
I was trying to get mitmproxy working on my iPhone 12, as dynamic libraries written in rust cannot be compiled to this target, causing a lot of problems when attempting to run open source projects on an iOS device which was quite capable.

[rust-highfive]

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

Please see the contribution instructions for more information.

[rust-highfive]

⚠️ Warning ⚠️

• These commits modify compiler targets. (See the Target Tier Policy.)

[wesleywiser]

Based on this comment, it seems like there are still several unresolved issues and merging this would re-introduce the issues that caused #77716 to be opened in the first place.

Is my understanding correct or have those issues been mitigated in another way and there is no longer a concern of breaking users?

Thanks!

[JohnCSimon]

Ping from triage:
@Torrekie Can you please address the question from the reviewer?

[Torrekie]

Based on this comment, it seems like there are still several unresolved issues and merging this would re-introduce the issues that caused #77716 to be opened in the first place.

Is my understanding correct or have those issues been mitigated in another way and there is no longer a concern of breaking users?

Thanks!

'breaking users' was not caused by 'dynamic linking' but 'crate-types' are not able to override by target specific configurations. rust-lang/cargo/#4881

Users could correctly build static or dynamic libraries for iOS by setting crate type in Cargo.toml before #77716, for iOS Apps that needs to be uploaded to App Store, they can just set crate type as static. Allowing dynamic linking is not stopping people from developing iOS Apps for production use, but loosing an option to build some dylibs to iOS for tests or other use. As this comment said, he's workflow would not able to cross compile rust libraries after compiler blocked iOS dylibs (and his distro still having large ammount users in iOS jailbreak community). Aren't users who were attempting to build iOS dynamic libraries 'breaking users'?

sorry for my terrible English tho

[wesleywiser]

Users could correctly build static or dynamic libraries for iOS by setting crate type in Cargo.toml before #77716, for iOS Apps that needs to be uploaded to App Store, they can just set crate type as static.

The problem as I understand it is that some projects have multiple crate types set and (prior to #73516) cdylib did not take effect for iOS targets. That's definitely not ideal but without something like rust-lang/cargo#4881 (as you mentioned), there's not really a good work around for existing users in this situation.

We discussed #77716 in the weekly compiler team triage meeting and concluded that merging it was the most appropriate action to take at that time. Since then, no new information has been discovered and the overall situation has not changed (the required features discussed at that time like rust-lang/cargo#4881 have not yet been implemented). Therefore to reverse that decision, we will need to have another conversation in the form of a Major Change Proposal that explains why that decision was incorrect, what the correct behavior should be, what work arounds are available to users in the situation described above and what the long term behavior should be taking into account proposed Cargo features.

Alternatively, I have a suggestion I did not see proposed in #77716: use a custom target JSON file which would allow you to set dynamic_linking: true for your custom target. You will also need to use the cargo build-std feature but I think that will do what you want. Does that seem like a potential path forward for you?

[Torrekie]

Currently I have a custom compiler with some modifications on my device that could let me create dylibs for Darwin targets. But bootstrapping full rust compiler to jailbroken iOS environment needs to compile rust for twice, which was spending much time: once for enabling rustc to build dylibs when iOS targets has been set, and use the compiler from first result to cross compile rust and rust toolchains to iOS (rustlibs cannot be built to iOS if rustc doesn't allow it).

But I still wonder if there is any future plans that regarding to those issues mentioned above. Allowing separate crate types for different targets would be pretty.

[bjorn3]

You can specify a custom json target spec with dynanic linking enabled when compiling rustc. Just pass the path to the json file instead of the target name. This saves the first bootstrap.

[JohnCSimon]

Ping from triage:
@Torrekie what is the status of this PR? Is it ready for review?

[JohnCSimon]

Ping from triage:
@Torrekie This PR hasn't seen any movement in the last two Months - I'm closing this as inactive. Please feel free to reopen when you're ready to continue. Thanks.

@rustbot label: +S-inactive

[dvc94ch]

@francesca64 cargo rustc now supports the --crate-type flag. Does that fix your build so dynamic library building can be reenabled for ios?

[francesca64]

@dvc94ch I've changed jobs, so I'm no longer involved; @ArthurKValladares is the new point of contact.

[dvc94ch]

Well, that's kind of great. Now this feature will never land because one day someone's build didn't work which no longer knows if the build is broken. I guess that is why you don't make concessions for these things. Does this mean that this needs a new rust edition to be enabled? @ArthurKValladares any comments?

[ArthurKValladares]

I would hate to see improvements to the language never landing because of work that has fallen on my shoulders. I'll dedicate some time in the next few days to bringing myself up to date on this issue and figuring if the --crate-type fix solves the problem we were running into.

[dvc94ch]

@ArthurKValladares I believe you're running into rust-lang/cargo#10356 can you try on nightly?

[ArthurKValladares]

@dvc94ch Yeah, this is the problem. I was under the impression that I was on nightly, but I was mistaken and everything worked after a rustup update. Sorry for deleting the old comment, I realized it was incorrect and was about to make a new comment with the updated information, but you beat me to the punch.

[dvc94ch]

@ArthurKValladares thanks for looking into this

@wesleywiser is that enough to reopen and merge this PR?

[dvc94ch]

Given the new evidence, I reopened the PR in #95847