[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:  kencu
      Type:  defect     |     Status:  closed
  Priority:  Normal     |  Milestone:
 Component:  ports      |    Version:  2.6.3
Resolution:  fixed      |   Keywords:  leopard
      Port:  libffi     |
------------------------+---------------------

Comment (by fhgwright):

 Actually, the build failure was just the tip of the iceberg.  I've been
 digging into this quite a bit, and the only cases with no known issues are
 10.7+ non-universal.

 A few notes:

 The compact-unwind warnings are just a harmless red herring, and are
 already happening on 10.7.  The source code doesn't create compact unwind
 - it creates DWARF unwind, which is then translated by a sufficiently
 recent linker into compact unwind in order to save space.  According to
 the Apple documentation, this began with 10.6.  I'm not sure whether
 there's any actual OS involvement, or whether "10.6" is just a proxy for
 "Xcode 3.2", but in any case, the reason the 10.5 linker doesn't support
 the  `-no_compact_unwind` option is that it has no knowledge of compact
 unwind at all.

 Using the integrated assembler never helps, and actually hurts on 10.6 if
 building with clang (which is desirable for some reasons), since the Xcode
 3.2 clang assembler is missing some needed x86_64 instructions.  I don't
 think it's worth the effort to figure out when, if ever, `-integrated-as`
 was actually useful.

 I came up with a fix for `sysv.S` that's actually a code improvement with
 a side effect of getting rid of the bug-tickling `.section` directive
 altogether.  With this change, it assembles successfully but runs afoul of
 the "bad length for GENERIC_RELOC_SECTDIFF" issue.  That seems to be a
 linker bug, since the object file is identical between the working and
 non-working cases, with only the linker being different.  Unfortunately,
 no Xcode 3.1 compiler choice avoids this linker bug (probably the same
 linker).  I was able to fix it for test purposes by rudely forcing the
 Xcode gcc 4.2 to use the MacPorts `ld64`, but that's not a viable approach
 for real.

 Building with apple-gcc42 is a possible solution, but that ''also''
 doesn't currently build on 10.5 i386.  It's also one of many gcc versions
 that produces bad assembly code for certain x86_64 floating-point cases,
 though I have a fix for that.

 You don't say how you got past the "bad length for GENERIC_RELOC_SECTDIFF"
 problem.  And note that using `__textcoal_nt` is a step backwards, since
 there are deprecation warnings about it.

 Aside from all that, the tests have issues both with the test framework
 and with actual bugs in `libffi`, some of which I've fixed here and some
 of which I haven't.  I hadn't planned on submitting a PR until I'd
 finished sorting it all out.

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