[MacPorts] #61170: libffi @3.3_1 fails to build on 10.5 i386

[MacPorts]

#61170: libffi @3.3_1 fails to build on 10.5 i386
------------------------+--------------------
  Reporter:  fhgwright  |      Owner:  (none)
      Type:  defect     |     Status:  new
  Priority:  Normal     |  Milestone:
 Component:  ports      |    Version:  2.6.3
Resolution:             |   Keywords:
      Port:  libffi     |
------------------------+--------------------

Comment (by fhgwright):

 I reran the builds with `buildmakejobs=1` for easier diffing, but I won't
 bother uploading them if you don't need them.

 > It is well known, as you point out, that the libffi assembler needs are
 advanced in nature, and no doubt the 32bit darwin part of it suffers more
 than most. We are trying to see if we can tweak it to build with the
 system toolchain, as otherwise our bootstrapping is complicated.

 Indeed.

 > We could consider salting away libffi 3.2.1 in a directory and building
 some llvm version against it (3.7?) that gets us to a current libffi
 version. But I'm hoping we don't have to do that as it just adds ever more
 complexity to supporting and bootstrapping these older systems that I
 would like to avoid.

 That would indeed be pretty ugly.

 The approach I suggested of splitting `llvm` would be a fairly clean
 approach (assuming `clang` doesn't need the external function interface),
 but it would be a nontrivial amount of work.  With the circular dependency
 gone, `libffi` could blacklist `gcc*` and unconditionally use
 `-integrated-as`.  That would be no change on later OS versions where
 `Xcode` supplies `clang`, but it would use a MacPorts `clang` on the
 earlier versions.

 In general, keeping compiler dependencies to an absolute minimum is good
 to avoid the circular dependency issues, and maximize the compiler choices
 for building something.

 There's a somewhat similar problem with `libcxx`, aggravated by the fact
 that it defaults to `+universal`.  When starting from scratch on 10.4 or
 10.5 `i386`, the default `+universal` adds  `ppc`, which blacklists older
 `clang` versions, while newer `clang` versions are blacklisted to avoid
 circular dependencies (unless already installed), leaving only `gcc`,
 which can't build `libcxx`.  One needs to manually install `libcxx
 -universal` to make it work.

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