On Dec 4, 2020, at 15:50, Mojca Miklavec wrote:
>
> You should be able to install MacPorts and many ports. But you should
> not be surprised if you hit some that will refuse to build and you may
> need to wait for upstream to fix the issue (or try to fix it yourself
> and submit a patch or find someone else capable of fixing it ...).
>
> You brought up an interesting point though, we should probably publish
> some official statement about arm support on our main website.
I don't think our statement would be very different from our stance with any
other new Apple product release, be it a new OS version or a new Xcode version:
probably some things are broken as a result and need to be fixed as the
problems are identified.
> A lot of relatively simple, well-written software with a well-written
> build system should often work out of the box.
Yes and no. Autotools is one of the oldest and still most widely used build
systems, yet until automake 1.16.3 which was just released a couple weeks ago
it misidentified Apple Silicon systems, so any port whose build system was
built with automake 1.16.2 or earlier may need to be autoreconfed to build
properly on Apple Silicon. libtool, which many autotools projects use,
misidentifies macOS 11 and later. Developers have not yet acknowledged the
problem, much less accepted our patch, so any software using autotools and
libtool and relying on undefined symbols being resolved at runtime will fail to
build on macOS 11 and will need to be either autoreconfed or patched or have
the deployment target set to 10.16. And then there's the implicit function
declaration problem biting lots of projects as of Xcode 12. Apple Silicon
systems are affected by all three issues, so in my opinion we have never had a
time in MacPorts history when more ports were broken at one time on a new
system than we have now. My recommendation continues to be if you want MacPorts
to work smoothly then do not upgrade to Xcode 12, do not upgrade to macOS 11,
and do not buy an Apple Silicon Mac. Or, if you do upgrade, be prepared to help
us resolve the issues you will inevitably encounter. Filing bug reports about
what's broken is a great start but we have a zillion open tickets already. What
we really need is for people to read those tickets and submit pull requests to
fix them properly.
> But a lot of software may either have some hard-coded assumptions in
> either their build system or the source, it may require some
> intel-specific intrinsics, or it may depend on some complex
> third-party library that doesn't compile. Apple also likes to increase
> security standards each year which may break many ports in various
> ways.
Yup, there are limitless ways that individual software packages could have done
it wrong in a way that doesn't work on Apple Silicon, above and beyond the big
three above.
> If you have your favourite port, you can quickly check the build
> results on, say,
> https://ports.macports.org/port/wget/stats
> and check for either green port status or some reported installations
> on arm64, check for open tickets etc. Keep in mind that many port
> builds haven't been attempted yet.
>
> (I also see that some builds like wget were successful, but missing on
> the list, while some like youtube-dl are redirected to the x86_64
> builder and also don't end up on that list.)
On Dec 4, 2020, at 17:34, Ken Cunningham wrote:
> Go here <https://ports.macports.org> and enter your favourite port.
>
> eg:
>
> <https://ports.macports.org/port/curl/summary>
>
> by the way, a “grey” box means untested as yet, not failing.
But please understand that the information on ports.macports.org is not
authoritative or complete.
A grey box does not mean untested. It means no information is available. Grey
means we might have built the port and it succeeded or failed, or we might not
have built the port yet.
Similarly, green or red does not guarantee that the most recent build succeeded
or failed. It just means that the most recent build *for which data was sent to
ports.macports.org* succeeded or failed. There may have been a more recent
build with a different status but which is not shown on the web site.
The reason for this is that ports.macports.org only shows status for ports that
were built directly. It does not show status for ports that were built
indirectly, for example as a dependency of another port. This situation is most
likely to arise when we first start building packages for a particular os/arch,
and happens less often after everything has been built once.
Authoritative information is the directory listings of
https://packages.macports.org. If there is a file, the build succeeded. If
there is not a file, then the build either did not succeed or was not attempted
or did succeed but the file is not legally distributable.
