In all MacOS 10.13 servers we see when running rustup
# curl --proto '=https' --tlsv1.2 -sSf https://sh.rustup.rs | sh
info: downloading installer
dyld: Library not loaded: /usr/local/opt/xz/lib/liblzma.5.dylib
Referenced from: /var/folders/nz/vv4_9tw56nv9k3tkvyszvwg80000gn/T/tmp.PKf7X779/rustup-init
Reason: Incompatible library version: rustup-init requires version 8.0.0 or later, but liblzma.5.dylib provides version 6.0.0
bash: line 411: 14010 Abort trap: 6 "$@"
I find this strange because it seems that rustup has been linked to a homebrew version of liblzma? And then it is falling back on /usr/lib/libzma.dylib on systems where a sufficiently new version is available? Is this really the intended design?
I think it would be better to statically link liblzma.a so that you don't introduce a runtime dependency on a certain version being available on the system.
It was working a week ago. It's failing now.
This must have come in with the 1.23.0 release.
@shepmaster is there anything you know of which could cause this?
Things I can find...
The logs for the 1.22.1 release have expired on github actions, however the 1.23.0 release was done on OS 10.15.7
It's not clear what the item which brings the newer liblzma into that github actions host image might be https://github.com/actions/virtual-environments/tree/main/images/macos however we could downgrade the build image to an earlier OS revision for CI builds if that would help.
Looking at things, we could cause liblzma to be statically linked into rustup. That might be more sensible since it essentially ends up so on most other platforms.
If I were to do that, I'd need some indication of how to verify that the resultant binary isn't dynamically linked to liblzma, what would be the macos equivalent of ldd target/release/rustup-init | grep lzma ? (I think otool -L target/release/rustup-init | grep lzma perhaps?)
Yes otool -L and I think you want to make sure you're not linking against anything under /usr/local.
Also maybe worth setting MACOSX_DEPLOYMENT_TARGET=10.13 ?
For C code we usually compile and link with clang -mmacosx-version-min=10.13
Also maybe worth setting MACOSX_DEPLOYMENT_TARGET=10.13
Rust defaults to 10.7 (11.0 on aarch64-apple-darwin). Choosing 10.13 will make it less compatible. That may or may not be what you want?
Rust defaults to 10.7 (11.0 on aarch64-apple-darwin). Choosing 10.13 will make it _less_ compatible. That may or may not be what you want?
That's certainly less good indeed, I'll back that out of my tweaked CI config.
The fixed build should now be live (1.23.1) Please let me know if it's not.