Support 10.6 as the target

[barracuda156]

Is it possible to support 10.6 target? Would be nice.

[madsmtm]

Rust itself (both language and compiler) no longer supports lower than macOS 10.12, see the platform support page. So it's impossible for core-foundation-rs repos to support a lower OS version.

[barracuda156]

Rust itself (both language and compiler) no longer supports lower than macOS 10.12

The plan is to re-introduce support, in order to support powerpc-apple-darwin target. But at the moment I wanna fix the build of an earlier version of rustc.

[madsmtm]

The plan is to re-introduce support, in order to support powerpc-apple-darwin target.

Interesting! Do ping me once you have more info on that.

[barracuda156]

For the reference, there is a discussion here: rust-lang/rfcs#1312
I honestly can’t say that much has been done ever since (due to lack of time, not interest), but I have added targets to mrustc earlier and right now re-arranging the existing port to switch it to 1.29, since that can be used with LLVM-7, which exists in a fixed version where codegen actually works (never did in upstream LLVM for this target).
I bumped into core-foundation when checking the sources, and that’s why this topic. If some 10.7-specific APIs are used, we will run into trouble once reach that point :)

Somewhat related, at least as of 2022, gccrs was building and mostly passing tests.
Rust-GCC/gccrs#1573 (comment)
Not sure about the status at the moment, I did not try it with recent versions. But gcc still supports the target, so chances are it gonna work, once gccrs as such works properly.

[barracuda156]

@madsmtm Just as an update on the status: I have fixed mrustc codegen to a point it can build rustc executable and libraries (at the moment 1.39.0, due to LLVM version requirements). However it chokes on creating LLVM target: apparently, something in specs is not correct and prevents it from acknowledging the needed triple from rustc side: thepowersgang/mrustc#300 (comment)

[barracuda156]

@madsmtm Ok, the time has come, now it becomes practically relevant: I got mrustc building Rust ports:

[madsmtm]

Cool!

The crates in this repo are somewhat soft-deprecated, see #729, but I'd be curious to know what you'd need from this project (or objc2) to be able to compile for macOS 10.6?

From what I understand, even if we unconditionally expose an API like kCFErrorURLKey, which is only available macOS 10.7, you will only get linker errors if there's code that actually tries to use it - and then the solution would be to change that code to no longer use that symbol (or dynamically import it with dlsym instead).

I guess we could do something like #110, but I'm kinda against relying on it in objc2 given that weakly imported symbols aren't stable in Rust (yet).

[barracuda156]

but I'd be curious to know what you'd need from this project (or objc2) to be able to compile for macOS 10.6?

I browsed through what MacPorts has that uses cargo, and a number of ports of interest use core-foundation and objc2-* crates. To be honest this won’t be the only obstacle, since a) until mrustc upstream releases 1.90 and we get it fixed for powerpc, I can only use 2018 (and occasionally 2011) syntax, b) mrustc supports a subset of rust, so here and there it gonna fail even with 2018, and the code has to be fixed to compile, c) of course nothing has ever been tested on < 10.7, forget powerpc, so for example libc lacks ppc64, libtarget ABI part lacks ppc64, libobject and backtrace has no proper support for powerpc, and on 32-bit powerpc we get another whole bunch of issues.
It will probably not work like it does with C/C++, where we can just require gcc with libstdc++, and everything just works, occasionally better than on modern macOS. Building any Rust app with mrustc is a challenge.

I am not really planning to get every Rust port to work, that gonna be both painful and unnecessary (most of apps have analogues in C/C++), but sooner of later a few python ports which moved to Rust gonna become a necessity (cryptography, pydantic, at least), and one thing which I would really like to have is a modern terminal emulator (for which there are a few options in Rust). Finally, apparently no one gonna write Signal implementation in C, but there is a one in Rust.
Not sure if anything of these is practically feasible, since all of these have hundreds of dependencies, and every time something gonna fail on the way (tbh, not that many crates are broken, but some are, and badly so – since it is unclear what exactly fails).

From what I understand, even if we unconditionally expose an API like kCFErrorURLKey, which is only available macOS 10.7

Yeah, we can’t do that indeed. Whatever is not supported in the SDK should either be excluded or replaced with custom implementations (like legacy-support does). Dynamically importing works only as long as something provides those symbols (and dyld finds them), otherwise an app just crashes at launch.

but I'm kinda against relying on it in objc2 given that weakly imported symbols aren't stable in Rust (yet).

Fixes can go into a separate branch/fork, or just live downstream in ports, if there are risks to merge them into master (or just bothersome to keep them there).