[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:  leopard
      Port:  libffi     |
------------------------+---------------------

Comment (by fhgwright):

 > The recommendation for Leopard i386 is to set the universal archs to
 "i386 x86_64".

 > Then it works exactly like SnowLeopard, and the portfiles all work
 properly. (Pretty much -- you have to do LibcxxOnOlderSystems manually if
 you want to use libc++)

 Having to change the configuration is more onerous than having to manually
 install a non-default variant.  Note that I wasn't trying to do anything
 with `libcxx` explicitly at all - this is just what happens when
 populating a new MacPorts install from scratch.

 The cheap fix would probably be just to make `libcxx -universal ` the
 default in cases where `+universal` causes trouble.  The only advantage I
 can see to the `+universal` default at all is to make it available as a
 binary archive, but binary archives have never been offered in the
 relevant cases, anyway.

 Defaulting to `+universal` should be done very sparingly in general, at
 least until `+universal` stops virally infecting all the build
 dependencies and causing massive build times.


 > disabling compact unwind and building with clang-3.4 is clean, though:

 > `configure.ldflags-append -Wl,-no_compact_unwind`

 > maybe that would help the build with gas succeed to link...

 Another question is whether a MacPorts `cctools` built with `Xcode gcc`
 would assemble this correctly.  That flavor of `cctools` isn't currently
 available, since `cctools +xcode` just copies the `cctools` from `Xcode`
 instead of building it.  If that approach does work, it would probably
 need to be something like `cctools-bootstrap`, to avoid variant conflicts
 with the "real" `cctools`.  Yes, another bootstrap kludge, but nowhere
 near as onerous as keeping an old `libffi` around.  And building with
 MacPorts `cctools` would behave more consistently than relying on varying
 `Xcode gcc/gas` versions.

 I presume the "unwind" here is unrelated to `libunwind`, though `libffi`
 seems to have an undeclared configure dependency on `libunwind`.  If
 `libunwind -universal` is active, then `libffi +universal` fails to
 configure, because "check if C compiler can make executables"
 opportunistically links against `libunwind` and fails if it's missing the
 needed architecture.  But with `libunwind` inactive, `libffi +universal`
 builds fine.  This is on 10.9, and has nothing to do with the current
 issue.

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