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.
