On Sep 12, 2022, at 14:02, chilli.namesake wrote: > On Sep 12, 2022, at 11:49, Eric Gallager wrote: > >> On Mon, Sep 12, 2022 at 9:29 AM Bill Cole wrote: >> >>> Why are you trying to to build it for i386, e.g. 32-bit? Is there some >>> dependent that can't be built for x86_64? >> >> There are cases where x86_64 will still get reported as i386 even >> though it isn't; on my x86_64 machine, for instance, `uname -p` and >> `arch` both report i386 even though it's x86_64. > > (note: my reply all does not include the list, annoyingly) > > That is pretty unsettling. > uname -p gives i386 > uname -m gives x86_86 > > I vaguely recall that in the past MacPorts has ignored the arch > specification. If macports.conf arch setting is ignored, is there a way I can > force x86_64?
Bill, you're barking up the wrong tree. Chilli, there's nothing wrong and nothing to fix here regarding the arch. The (lib)gcc9 port is printing the value of the MacPorts os.arch variable as part of its error message to you. On any Intel Mac (32-bit or 64-bit), that will be "i386", just as on any PowerPC Mac (32-bit or 64-bit) it will be "powerpc" and on any Apple Silicon Mac it will be "arm". See https://guide.macports.org/#reference.variables os.arch is based on the same source of information as "uname -p" which tells you the processor family. On Intel Macs, "uname -p" gives you "i386"; on PowerPC Macs, it's "Power Macintosh", and on Apple Silicon Macs it's "arm". Compare and contrast with the MacPorts build_arch variable which indicates both the processor family and the bit size to use: here, "i386" would mean 32-bit Intel; "x86_64" would mean 64-bit Intel; "ppc" would mean 32-bit PowerPC; "ppc64" would mean 64-bit PowerPC; and "arm64" would mean 64-bit ARM. "uname -m", for your reference, tells you the architecture of your kernel. Not particularly relevant to MacPorts, since it's totally fine to be on a 64-bit Intel Mac but use a 32-bit kernel. Several Macs were configured by Apple to do that in the Mac OS X 10.6/10.7 days.
