Universal and its many meanings

[Wowfunhappy@gmail.com]

For the past couple of weeks, I've been enjoying following this discussion on Github, even though I only understand a minority of what is being said: https://github.com/macports/macports-ports/pull/13995. They keep brushing up against a topic which seems to me like a wider issue with MacPorts: its overloaded definition of "universal".

As I understand it, +universal is used to mean two different things in MacPorts:

1. Install this port as a universal binary, which contains slices for multiple architectures. For the purposes of this message, I'm going to refer to these as "fat" binaries.

2. Install this port with the ability to create fat binaries with slices for multiple architectures. For the purposes of this message, I'm going to refer to these as "cross-compilers".

These are not the same thing. I could have a thin intel compiler which will never be able to run on a arm mac, but which is nonetheless capable of producing both arm and intel code, and by extension thick arm-intel binaries. Similarly, I could have a thick arm-intel compiler which can be executed on both arm and intel Macs, but which cannot cross-compile intel code from an arm machine. I suppose I could even have a thin intel compiler which can only produce arm code, although that would be bizarre.

Replace arm and intel with any specific architecture, including "ppc32", "i386" and "x86_64".

When a port fails to install as +universal, the word's multiple definitions make it difficult to figure out what's wrong. MacPorts can build gcc7 for both intel and ppc (and so I think it could theoretically build a fat intel-ppc binary), but gcc7 cannot itself cross-compile ppc code on an intel machine, and vice versa. This causes other ports to fail to install as +universal for these two architectures.

This is a perfectly acceptable limitation. On platforms that are more than a decade old, I'm always delighted that ports work at all! While I can't speak for others, I as an onlooker think it's a shame that catap et al's attempts to get newer toolchains on Snow Leopard are currently running into universal-related roadblocks. It should be possible to simply drop support for either fat binaries or cross compilers or both, and maybe come back to the issue later. However, if something isn't supported, it should be obvious to the user what that is.

Although, on a completely separate note, I don't understand why many of these problems can't be trivially solved by a combination of the lipo and Apple's built-in translation layers (namely Rosetta 1/2 or x86_64's native 32bit support). If e.g. gcc7 is installable on both Tiger ppc and Tiger intel, and Tiger intel can run ppc binaries via rosetta, shouldn't it be possible to just (1) compile the code with gcc7_intel, (2) compile the code with gcc7_ppc, and (3) lipo the results together?

This would become all the more desirable if something like https://trac.macports.org/ticket/60878 is ever implemented. The buildbot could compile a port on whatever architecture it wants and lipo the pieces as needed.

---

That was a lot, I hope it all made sense!
–Wowfunhappy
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.macports.org/pipermail/macports-dev/attachments/20220226/3c835cfa/attachment.htm>