[MacPorts] #64390: Possible to build ports on 10.6.8 as universal (x86_64 + ppc64) after restoring PPC assembler?

[MacPorts]

#64390: Possible to build ports on 10.6.8 as universal (x86_64 + ppc64) after
restoring PPC assembler?
-----------------------------+--------------------
  Reporter:  barracuda156    |      Owner:  (none)
      Type:  enhancement     |     Status:  new
  Priority:  Normal          |  Milestone:
 Component:  base            |    Version:  2.7.1
Resolution:                  |   Keywords:
      Port:  powerpc, ppc64  |
-----------------------------+--------------------

Comment (by kencu):

 llvm-gcc42 was Apple's transition compiler heading to clang. It used
 gcc-4.2 as the front end and llvm as the back end to generate code. As
 llvm has never been able to generate coherent powerpc code, llvm-gcc42
 never could either.

 /usr/bin/gcc-4.2 (apple-gcc42) is the very old, basic compiler that comes
 as the system compiler on 10.5 and 10.6, and we add it to 10.4. It is
 useful these days only for quite basic things, as a very large percentage
 of the code base in macports cannot be compiled with gcc-4.2 any longer
 (it has no c++11 or c11 support, no thread_local support, and no support
 for many other modern coding constructs).

 If you try to make gcc-4.2 your default compiler a large large number of
 things will not build.

 If really wanted to make a toolchain for 10.6.8 that could generate
 universal x86_64 and powerpc64 code then you realistically have two
 choices:

 1. work with Iain to get llvm finished to be able to output reliable
 powerpc code. This would probably be the best option, but I've been after
 this for five years so far :>
 2. build a new gcc cross compiler that has both intel and power
 components, lipo them together into one big compiler (just like apple-
 gcc42 does) and write an updated front-end (driverdriver.c) that handles
 the arch flags and lipos the build products together.

 Option 2 is doable today -- that is exactly what Apple did for gcc-4.2
 after all, and all that code is sitting there in the apple-gcc42 port.

 However, it's a fair project to complete, the front end needs to be
 updated, and the tooling in MacPorts would need to be all adjusted to
 manage it.

 I have considered this at times -- it's easy enough as nothing needs to be
 invented -- but in the end, I decided that for me at least, there was
 little point.

-- 
Ticket URL: <https://trac.macports.org/ticket/64390#comment:3>
MacPorts <https://www.macports.org/>
Ports system for macOS