[MacPorts] #63443: ffmpeg-4.4_3+gpl2: build failures: libffi dylib version bump breaks core ports like LLVM (was: ffmpeg-4.4_3+gpl2: build failures: possibly related to libffi)

MacPorts noreply at macports.org
Fri Oct 15 17:47:24 UTC 2021


#63443: ffmpeg-4.4_3+gpl2: build failures: libffi dylib version bump breaks core
ports like LLVM
------------------------+----------------------
  Reporter:  Tommaso93  |      Owner:  jeremyhu
      Type:  defect     |     Status:  assigned
  Priority:  Normal     |  Milestone:
 Component:  ports      |    Version:  2.7.1
Resolution:             |   Keywords:
      Port:  ffmpeg     |
------------------------+----------------------

Comment (by mascguy):

 Replying to [comment:14 msbit]:
 > When troubleshooting the issue, I had tried to run `nm` on some of the
 output `.o` files, but that had failed with:
 >
 > {{{
 > dyld: Library not loaded: /opt/local/lib/libffi.7.dylib
 >   Referenced from: /opt/local/libexec/llvm-10/lib/libLLVM.dylib
 >   Reason: image not found
 > }}}
 >
 > which seems to be due to a big migration from `libffi.7.dylib` to
 `libffi.8.dylib` that happened while I'd been neglecting this machine?

 Just experienced a similar situation, with some macOS VMs that were at
 least a month out-of-date [in terms of MacPorts].

 What's clear is that a libffi upgrade temporarily breaks foundational
 ports like LLVM, when the dylib major version changes. And that seems like
 a big problem.

 To avoid this situation, I'd like to update libffi to create a dylib
 symlink, with the previous major version. So when it's updated to
 `libffi.8.dylib`, for example, symlink `libffi.7.dylib` to it. This will
 prevent breakage of LLVM, and these related headaches. (The port would
 determine the previous relative major version, from the current built
 version. So nothing would be hard-coded.)

 Thoughts?

 Longer-term, perhaps LLVM components should utilize a separate libffi. I'm
 thinking in terms of how we avoid circular dependencies among toolchain
 components, by utilizing separate "bootstrap" ports. (So perhaps utilize a
 `libffi-bootstrap` for all LLVM/toolchain components.) Or alternatively,
 statically link with libffi... assuming that doesn't cause issues?

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


More information about the macports-tickets mailing list