Rust 1.44.0.0 won't compile on macOS Sierra 10.12.6 and Trac ticket # 56351

[Ryan Schmidt]

On Jun 25, 2020, at 06:28, Greg Earle wrote:

> I did a "port upgrade outdated" and it looks like "librsvg" has a dependency on Cairo which in turn pulls in Rust.  (I didn't have Rust installed previously.)

cairo absolutely does not require rust. librsvg however does. rust is a programming language and recent versions of librsvg are written in this programming language so there's no avoiding that dependency if you want a recent version of librsvg.

The librsvg port adjusts itself to use the recent rust-based librsvg on systems that can build rust (currently 10.11 and later), and downgrades itself to the older C-based librsvg on older systems that can't (currently 10.10 and earlier). Rust seems to move forward quickly and become incompatible with not-even-very-old systems faster than I would like. So it's possible that the cutoff points in the librsvg port need to be adjusted.


> There don't seem to be any pre-made Rust binary bundles for Sierra, so it tries to build it from src and fails:

Just to cross-reference it, you've (I assume it's you) also filed a ticket about this:

https://trac.macports.org/ticket/60714

Rust apparently claims to work with Mac OS X 10.7 and later, but obviously this is untrue. The only way support for older systems will improve is if people like you who are interested in rust continuing to support older systems speak to its developers and make your voices heard, and ideally help them with whatever problems are preventing rust from working on older systems.

https://github.com/rust-lang/release-team/issues/2

Or it's possible like Ken mentioned that your issues are just related to you trying to build librsvg universal, which won't work for the rust-based librsvg; build it non-universal.


> I seem to be hitting the same issue as described by Marcus Calhoun-Lopez back in 2018:
> 
> https://trac.macports.org/ticket/56351
> 
> https://github.com/rust-lang/rust/issues/50220
> 
> but that bug report was for High Sierra 10.13.4.
> 
> Most of the additions from his workaround in commit
> 
> https://github.com/macports/macports-ports/commit/e429b4d8a8b2667f23110596fbe7ebee9f28d72e
> 
> don't seem to be in the present rust/Portfile, which seems to have varied enough from the one he based his commit on that I'm not comfortable changing anything.

That commit, "rust: allow build if llvm is universal", was essentially reverted:

https://github.com/macports/macports-ports/commit/8aa429ba73845ced50d6e629bdfc681f010bcfaf

rust no longer supports anything other than x86_64. If you don't like that (as I don't), you can complain to the developers of rust.


On Jun 25, 2020, at 07:02, Ken Cunningham wrote:

> if you have librsvg installed as +universal, then it will no longer upgrade.
> 
> rust no longer builds +universal. I think we should fix that, but I tried and indeed it's non-trivial.
> 
> That's <https://trac.macports.org/ticket/60438>.
> 
> In the meantime, as per that ticket, all you can do is edit the portfile to enable the last "C" version, which is quite outdated now. Ryan knows this and didn't do that, so I assume he's waiting for a rust +universal miracle instead.

I'm not waiting for any miracle or planning to do anything about it. rust and librsvg and other ports that use rust are not my ports. I commented on the PR in which it was suggested to remove the i386 parts. There is a difference between the architectures for which a compiler is installed and the architectures for which that compiler can build. I had hoped even though rust would only be compiled as an x86_86 executable that it could still compile i386 code. Once the PR was merged, it became apparent that that was not the case, at least not with the way that the port was programmed. I filed the ticket about those problems, hoping that there was a way to adjust the port so that this would still be possible, but there has been no response from those whom I Cc'd on that ticket. It's up to those maintaining those ports to do something about it.

It seems like a difficult problem to do anything about. One option is what you suggested, to downgrade librsvg to the last C version. Doing so for all users would mean we never update librsvg again, which would be bad. Doing so for just the +universal variant would mean users get a different version when building universal vs non-universal, which would be unexpected (and the portindex is not designed to accommodate ports that change their version in a variant). It would mean that software built against librsvg non-universal would fail if librsvg +universal were installed, which would be bad. Another option is to disable the universal variant in librsvg. Doing so for all users, even those on older systems using the C version of librsvg that can be built universal, would be bad, and would require modifying all ports that depend directly or indirectly on librsvg to disable their universal variants too. Doing so only for the rust version of librsvg would be messy, since the code that decides whether to enable or disable the universal variant based on OS version would need to exist not just in the librsvg port but also in all ports that depend directly or indirectly on librsvg, and that OS version might need to be adjusted in all those ports as rust evolves. And bear in mind that some of those ports use librsvg only in a variant, so that changes how those restrictions would have to be implemented. The preceding complications are another reason why I wasn't planning on involving myself in the fix for this issue. I have enough other things to work on.