target sdk version support

[Gankra]

When making prebuilt binaries you "need" to decide how old of a system you're willing to support. i.e. if you want to rely on APIs introduced in windows 10, your binary won't necessarily work on windows 8.

Currently this is a big shrug and I think cargo/rust just uses whatever's available on the machine that built the binary (similar to target-cpu=native) that we only address by generating CI that uses the oldest (non-deprecated) Github runners.

Ideally we would help the user here with choosing SDK versions and getting everything setup to do that. Unfortunately this is 100% outside my domain of expertese and I have absolutely no idea how to do this for the 3 big desktop platforms!

[Gankra]

musl (#75) is one partial way to punt on this completely when targeting linux (although presumably musl still has to care about kernel versions and if you depend on openssl or whatever then you're still dealing with SDK versions to some extent).

[lenary]

Here are some thoughts from a "Packaging C/C++ Applications" viewpoint, on your three platforms:

• Apple Platforms: I believe the correct way is to use -mmacosx-version-min= and -mios-version-min= in clang, and the equivalents for ld64 to tell the toolchain what you have available, and this should work. I believe the easiest way to package software is to statically link everything, except libSystem which must be dynamically linked (it's where the c library lives, amongst other things). I don't know how this works for Rust, which presumably still uses libSystem, but doesn't really use e.g. C headers.
• Windows: I'm least familiar with this, but when programming in C/C++, there are defines you can use so you don't use an SDK that is too recent, but I cannot find the right docs for them this evening. This may not apply to Rust, and you may just have to care about the CRT which is easier, and I think you have the answer for.
• Linux: This is where the fun starts. Again, the easiest way forwards is to statically link everything (you can do this with musl), or everything except glibc (which is a more standard approach). If you dynamically link glibc, that's where the fun starts. There's no easy way of limiting the glibc symbol versions your linker will choose, it will choose the most recent version on your system of any symbol it needs to dynamically link. So, the ways forward are either to make yourself a sysroot containing the headers and libraries you need of a sufficiently old version of glibc, or to use something like https:/phusion/holy-build-box to ensure the whole build can only ever see an old glibc.

I don't know Rust's default linking model for crates (presumably it's static linking everything that was Rust code), but presumably as soon as you use FFI into C, you can break out of "statically link everything", so you might have to have a think about shared objects, especially where you might want to use the underlying system's shared libraries, so you don't have to rebuild your whole binary when a new version of openssl comes out.

Hopefully these are useful pointers to get started. When I find the windows link I was thinking of I will send it over.

[lenary]

This is the link for windows, which means it was very much aimed at headers not at something deeper (the MacOS sdk argument for ld64 does additional checking based on the min version): https://learn.microsoft.com/en-us/windows/win32/winprog/using-the-windows-headers

[mstange]

I'd like to reiterate that on macOS, the chosen SDK is independent of the minimum supported version. And you can set the minimum supported version by doing MACOSX_DEPLOYMENT_TARGET=10.7 cargo build.