macports-base icon indicating copy to clipboard operation
macports-base copied to clipboard

Add opt-in Altivec (ppc7400) architecture

Open evanmiller opened this issue 3 years ago • 10 comments

Address https://github.com/macports/macports-ports/pull/11625 with a modest proposal to add a new ppc7400 architecture. The idea is that this Altivec-enabled architecture will be preferred on G4/G5 machines but fall back to regular ppc if not available. When properly implemented in Portfiles, G3 users should no longer see the dreaded incompatible cpu subtype run-time error message.

Support for the ppc7400 architecture is completely controlled by the individual Portfiles, which need to declare support in supported_archs and then pass appropriate configure and compiler flags for Altivec (ppc7400) and non-Altivec (ppc) builds. Existing Portfiles do not require modification (it's OK if ppc builds are secretly Altivec builds), but this PR will provide the tools for maintainers to replace run-time hardware detection with branching on ${configure.build_arch}, or to declare that a port absolutely, positively requires Altivec on PowerPC (e.g. mpg123). See the commit message for a more complete explanation and rationale.

Rudimentary testing performed but I do not have access to a G4/G5, and I also have no idea if universal builds will work here. Earlier, someone suggested supporting ppc + ppc7400 universal builds, which would be a neat trick for binary distributions.

Opening this PR as a draft to discuss the concept and field suggestions. Note that this general strategy might also be used for advanced Intel ISAs (e.g. AVX2 and AVX-512) though that's outside the current scope here.

evanmiller avatar Aug 22 '21 03:08 evanmiller

The problem I see with this is there are hundreds of ports that run the list of supported arches, branching on the build_arch or configure.build_arch.

ppc7400 is not recognized by any of these Portfiles, and I doubt they want to add specs for this for the 0.0001% coverage it would add.

IMO the simplest thing to do in the relatively few ports that build differently with or without altivec is something like this in the PPC block:

if (altivec available) {
  add_altivec_enabling_option whatever_it_is
} else {
  # clear archive sites forcing a local build should a buildbot someday exist
  archives_sites
}

This presumes only that any PPC buildbot someone sets up would be at least an altivec-capable machine, and we can put that as a requirement someplace if we like. I don't think this is unreasonable at all.

It gets around this theoretical problem very clearly, with minimal disruption, no complicated variants, and minimal added effort in Portfiles.

Many ports already have the first 1/2 of this, and just need the second half added to cover it off.

kencu avatar Sep 11 '21 23:09 kencu

Just to be clear, ppc7400 is not included in the new default value of supported_archs (see change to src/port1.0/portmain.tcl). So ports that iterate over supported_archs will not see it - or am I missing something? (If ports are iterating over sdk_archs that is a different matter...)

evanmiller avatar Sep 12 '21 03:09 evanmiller

so let's say you set up your G3 system with a build_arch of ppc7400 specified in macports.conf (I assume that is what you mean users to do with this).

And you get to one of the many many ports that iterates over the known build_archs (ppc, ppc64, i386, x86_64, arm64 at present). There is no entry in any of those Portfiles for ppc7400, so the branching logic that branches on the build_arch will fail.

Modifying them all is not reasonable to ask.

The solution I suggest is incredibly simple and unobtrusive, and solves the problem fairly elegantly (with the proviso that a PPC buildbot would have to be a G4 or better). It seems so much simpler to me to do that.

kencu avatar Sep 12 '21 19:09 kencu

Sorry I guess I had it backwards. G3 users you propose would leave their build_arch as the default ppc, and anyone with a G4 or G5 be asked to set their system up with ppc7400 in macports.conf to get altivec? Perhaps I am not fully following how this might work transparently without any changes in any portfiles.

I still think clearing archive_sites on G3s when needed is a very simple solution to the issue though.

kencu avatar Sep 12 '21 19:09 kencu

ppc vs ppc7400 is now auto-selected (via [sysctl hw.vectorunit]) in src/macports1.0/macports.tcl – no changes are needed to anyone's macports.conf.

The idea is that ppc is a fall-back architecture for ppc7400, just as i386 is a fallback architecture for x86_64 (and ppc is a fallback for ppc64). Ports iterating over build_archs should not see ppc7400 unless they explicitly put ppc7400 into their own supported_archs.

If you can point me to an example of a Portfile that you think will need modifying I will be able to understand your concerns better.

evanmiller avatar Sep 12 '21 19:09 evanmiller

Reading it over some more, I see what you mean.

I think it could be made to work -- like arm64 was made to work -- as it is, I'm not sure about things like the muniversal PortGroup and ports that iterate over the folders in there of various archs, or meson with it's universal enhancements I added, etc, etc. None of those consider ppc7400 as an arch to work with. So it could be made to work, but I think pitfalls still seem likely.

It's clever. I continue to push for the practical simplicity of clearing archive_sites on G3s for the few ports that build differently with altivec, as -- to be honest -- there is likely not much enthusiasm for taking on such a project to support G3s when a simpler alternative is readily available.

PPC usage in MacPorts as a whole is a very tiny portion of the user base -- you may well be the only active G3 user we have. There is only so much effort to be expected to support that base.

I am just now in the process of switching several of my G5s over to Debian 10, which has some future as an OS.

kencu avatar Sep 12 '21 21:09 kencu

Yeah I was afraid that the universal stuff may prove the downfall of this approach.

Hardware checks in a Portfile make me wince a little bit – but only a little, and I'm fine with your solution if I/we can sell it to MacPorts. The other discussants didn't seem too keen on it.

The separate architecture outlined here seems "right" to me – but really I just want to be able to port install libjpeg-turbo on a G3 on not have it barf on me at run-time. I'm fine with either approach, but mainly just want a clear policy in place so that I know how I should be fixing ports to run on G3s.

evanmiller avatar Sep 12 '21 22:09 evanmiller

I'm blessed with two PPC Macs - a 2001 iMac G3, and a 2004 PowerBook G4 (with a 7450, I believe).

So if you need any additional help testing these changes, let me know!

mascguy avatar Oct 28 '21 00:10 mascguy

So if you need any additional help testing these changes, let me know!

Thanks! I'm going to let this one sit until the individual ports are working on G3 and there is a cross-compilation story that needs addressing. libjpeg-turbo and OpenBLAS seem to be the last hold-outs.

evanmiller avatar Oct 28 '21 16:10 evanmiller

I have an iBook G4 that I'm willing to use to test stuff for you if it is still needed.

hamishmb avatar May 01 '22 19:05 hamishmb