Closed saurik closed 4 months ago
briansmith
commented
4 months ago Yes, you can use cargo update -p cc to update your Cargo.lock to the latest version of cc-rs, and/or you can update to a specific version with an additional argument. The version in ring's Cargo.toml is the minimum version supported, not the maximum or only version.
saurik
commented
4 months ago @briansmith You say "your Cargo.lock", but again: I'm not writing Rust code, I'm merely compiling it... are you saying I have to modify the project I'm compiling in order to, for example, target tvOS, if there is a transitive dependency on ring? All of my dependencies are effectively read-only, so, in addition to that feeling extremely dirty, I simply don't have a good way to do that. Is there really no way to do this using a command line argument or an environment variable or something to merely override the version of cc-rs that is being used during cargo build? :(
briansmith
commented
4 months ago Is there really no way to do this using a command line argument or an environment variable or something to merely override the version of cc-rs that is being used during cargo build? :(
Yes, there is, and it doesn't require any changes to ring and there's nothing ring-specific about it. It would be good for you to ask your question in a forum.
The version of cc-rs being used is currently 1.0.83 for every platform except specifically VisionOS, which uses 1.0.97. Version 1.0.84 happened to make some particularly useful updates to the command line arguments passed to compilers when targeting iOS, including specifically that they finally stopped using -fembed-bitcode (which frankly never should have been supported for any platform other than watchOS: Apple never required it and even they realized it was a bad idea and dropped it).
There are also other fixes I'm interested in from newer versions of cc-rs, including changes to the handling of -isysroot, support for tvOS, improvements to the search path for Mac Catalyst, etc. Essentially, there is a ton of updates to cc-rs that feel useful to me as a person trying to compile projects (which happen to be written in Objective-C++) that happen to use libraries written in rust that depend on ring which is pinning an old version of cc-rs, which is awkwardly a library rather than a build tool.
Is there a reason why ring requires a specific version of cc-rs that is almost a year old? The issue with how this is set up is that the fleet of compilers used isn't really up to ring: it is a negotiation between the person attempting to do the final build passing flags to cargo to configure rustc, with cc-rs as something of a depressing hack that attempts to reimplement some of the logic, and so if you are stuck on an old version of cc-rs it causes issues when using newer toolchains with newer rustc/cargo.
(FWIW, if there's some easy way to use a command line argument or an environment variable or something to override the version of cc-rs that is being used I'm very interested in and would happily use such a workaround. I'm not actually a rust developer: I just use rust libraries in my ObjectiveC++ code as dependencies, and thereby am constantly feeling like I'm running into limitations in build tooling, so I already have tons of crazy workarounds to get access to target-applies-to-host=false, etc.)