Macos ci tweaks

[kinnison]

This may fix #2583 if we're lucky

[kinnison]

@jeroen how do you feel about this?

[kinnison]

I think this is good, the otool output suggests it's not dynlinking liblzma - @shepmaster do you think this is okay? If so, I'll try and prep/stage a 1.23.1 ready for @pietroalbini or another t-release member to do a release tomorrow.

[jeroen]

I don't understand how this changes anything, LZMA_API_STATIC is a preprocessor macro that is only relevant on Windows, I don't think it changes the linking behavior?

[kinnison]

I don't understand how this changes anything, LZMA_API_STATIC is a preprocessor macro that is only relevant on Windows, I don't think it changes the linking behavior?

It's an environment variable which controls how lzma-sys links the library. In static mode it will not dynamically link to it.

The otool output in the completed actions run here suggest it has succeeded in that.

[jeroen]

Ah okay I wasn't aware that lzma-sys uses the same name as the C macro.

I'm not 100% confident the otool diagnostic is correct, did you confirm that the dylib shows up before the fix? Also maybe you should explicitly fail if there are links to /usr/local/ to prevent the same problem from appearing in other libs. The same may happen with for example libcurl.

GHA images have hundreds of 3rd party homebrew libs preinstalled and they get updated for each release so if you don't want to depend on those, I think the safest method is to get them out of the way.

On my GHA jobs that build deployed binaries, I always first uninstall homebrew, or the cheaper version:

rm -f /usr/local/lib/*.dylib

So then you can be confident you're not accidentally linking to locally installed 3rd party libs.

[kinnison]

I did not check the otool output before the fix, but that's easy enough for me to try. I only worry that clearing /usr/local/lib might break other things, but I'm not a macos expert.

[shepmaster]

The changes in general seem reasonable. I don't suppose there's a way of getting that artifact so that @jeroen can test it locally?

[kinnison]

I've not worked out how to exfiltrate artifacts from gha builds without yet another s3 bucket somewhere.

[kinnison]

Okay, so I can confirm that without the fix, otool shows /usr/local stuff present in the link. I'll see if I can make that cause a failure next.

[kinnison]

Yep, that worked. I'm now trying a run where we save the artifacts, if that works then @Jeoren can try the new macos build?

[kinnison]

@jeroen Any chance you can test https://github.com/rust-lang/rustup/suites/1578429346/artifacts/28537948 ?

[jeroen]

Thanks! I've tested this on VM's with MacOS 10.11 and 10.13 and both work.

[kinnison]

@jeroen Fantastic, thank you.

[Jeoren]

Hi guys: I don’t know how you used the GitHub email system. But I am not the ‘Jeroen’ who should be working on the project. Please recheck the email address. Best regards Jeroen Xie

…

在 2020年11月30日，上午12:12，Daniel Silverstone ***@***.***> 写道：  Yep, that worked. I'm now trying a run where we save the artifacts, if that works then @Jeoren can try the new macos build? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or unsubscribe.

[kinnison]

@Jeoren Sorry, that was a typo on my part, I apologise for the spam.

[Eric-Arellano]

Hey @kinnison, thank you for promptly fixing this!

It sounds like you're planning a 1.23.1 release soon. That would help us a lot over at https://github.com/pantsbuild/pants for how we install Rust in our CI.

Thanks for all you do for the Rust ecosystem! 🦀