info

[Ryan Schmidt]

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.