[MacPorts] #69380: libffi fails on 10.5 PPC for bad patch

[MacPorts]

#69380: libffi fails on 10.5 PPC for bad patch
-----------------------+-------------------------
  Reporter:  rmottola  |      Owner:  (none)
      Type:  defect    |     Status:  new
  Priority:  Normal    |  Milestone:
 Component:  ports     |    Version:
Resolution:            |   Keywords:  leopard ppc
      Port:  libffi    |
-----------------------+-------------------------

Comment (by fhgwright):

 Replying to [comment:3 rmottola]:
 > Being the patch for intel only, I removed it as a test from the portfile
 and it compiled on PPC.

 In general, conditionally-applied patches are a bad idea.  If at all
 possible, any conditional behavior of patches should be ''within'' the
 patches, not in whether to apply them.  The idea is to create a single set
 of modified sources that works in all cases.  Ideally, this should even
 mean being acceptable for non-Mac systems, with the goal of being
 acceptable as upstream changes (whether or not upstream actually accepts
 them).

 And version updates should revalidate patches, and update them as needed.
 Messages like
 {{{
 Hunk #3 succeeded at 1262 with fuzz 2 (offset 142 lines).
 }}}
 mean that someone hasn't done their homework.

 Replying to [comment:8 kencu]:
 > That ain’t good, as libffi needs to work….it underpins a number of other
 ports.

 Sort of, though it's sometimes only for ancillary uses.  For example, the
 `llvm` port depends on `libffi`, but AFAIK the core compiler part of
 `llvm` doesn't use `libffi` - it's just for things like the language
 bindings.  If the port were properly partitioned into core and extras
 subports,there would be no issue with circular dependencies even when
 building with `clang`, since the dependency chain would then look like:
 {{{
 llvm-extras -> libffi -> clang -> llvm-core
 }}}
 I see that `clang-3.*` have dependencies on `libffi`, but I'm not sure if
 those are legit.  More recent versions of `clang` don't.

 Replying to [comment:14 ballapete]:
 > I think `libff @3.4.6` works fine! I "played" a bit with make/gmake in
 `testsuite/libffi.bhaible`, built the two test programmes and ran them
 manually. The results, the failures, are these:
 >
 > {{{
 > ...
 > }}}
 >
 > I think this can be expected. The `PowerPC G4 CPU` is only 32 bit.
 Possibly this physical limitation produces the failures. Using a different
 math library might resolve the issues…

 The integer bitness doesn't affect the floating-point bitness, and there's
 no math library involved when doing basic FP on a CPU with FP hardware.
 What `libffi` has to get right is the way that various function arguments
 and results of various types are passed around on the stack and in
 registers.  The ABI docs often fail to spell out the corner cases
 adequately, and sometimes `libffi` guesses wrong.

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