[MacPorts] #70882: OpenCore Legacy Patcher 2.0.2 installs faulty CoreImage framework on macOS 15 on Macs using 3802-based GPUs

[MacPorts]

#70882: OpenCore Legacy Patcher 2.0.2 installs faulty CoreImage framework on macOS
15 on Macs using 3802-based GPUs
-------------------------------------------------+-------------------------
  Reporter:  RivetBenoit                         |      Owner:  (none)
      Type:  defect                              |     Status:  assigned
  Priority:  Normal                              |  Milestone:
 Component:  ports                               |    Version:  2.10.1
Resolution:                                      |   Keywords:  sequoia
      Port:  ffmpeg, ffmpeg6, ffmpeg7, ffmpeg-   |
  devel                                          |
-------------------------------------------------+-------------------------

Comment (by ryandesign):

 Replying to [comment:31 kampfflunder]:
 > What I do not understand: While linking, I get the known errors:
 > {{{
 > --->  Scanning binaries for linking errors
 > Incompatible library version: /opt/local/bin/ffmpeg requires version
 1.0.1 or later, but
 /System/Library/Frameworks/CoreImage.framework/Versions/A/CoreImage
 provides version 1.0.0
 > Incompatible library version: /opt/local/bin/ffplay requires version
 1.0.1 or later, but
 /System/Library/Frameworks/CoreImage.framework/Versions/A/CoreImage
 provides version 1.0.0
 > Incompatible library version: /opt/local/bin/ffprobe requires version
 1.0.1 or later, but
 /System/Library/Frameworks/CoreImage.framework/Versions/A/CoreImage
 provides version 1.0.0
 > Incompatible library version: /opt/local/lib/libavdevice.58.13.100.dylib
 requires version 1.0.1 or later, but
 /System/Library/Frameworks/CoreImage.framework/Versions/A/CoreImage
 provides version 1.0.0
 > Incompatible library version: /opt/local/lib/libavfilter.7.110.100.dylib
 requires version 1.0.1 or later, but
 /System/Library/Frameworks/CoreImage.framework/Versions/A/CoreImage
 provides version 1.0.0
 > Incompatible library version: /opt/local/libexec/ffmpeg7/bin/ffmpeg7
 requires version 1.0.1 or later, but
 /System/Library/Frameworks/CoreImage.framework/Versions/A/CoreImage
 provides version 1.0.0
 > Incompatible library version: /opt/local/libexec/ffmpeg7/bin/ffplay7
 requires version 1.0.1 or later, but
 /System/Library/Frameworks/CoreImage.framework/Versions/A/CoreImage
 provides version 1.0.0
 > Incompatible library version: /opt/local/libexec/ffmpeg7/bin/ffprobe7
 requires version 1.0.1 or later, but
 /System/Library/Frameworks/CoreImage.framework/Versions/A/CoreImage
 provides version 1.0.0
 > Incompatible library version:
 /opt/local/libexec/ffmpeg7/lib/libavdevice.61.1.100.dylib requires version
 1.0.1 or later, but
 /System/Library/Frameworks/CoreImage.framework/Versions/A/CoreImage
 provides version 1.0.0
 > Incompatible library version:
 /opt/local/libexec/ffmpeg7/lib/libavfilter.10.1.100.dylib requires version
 1.0.1 or later, but
 /System/Library/Frameworks/CoreImage.framework/Versions/A/CoreImage
 provides version 1.0.0
 > }}}

 To clarify: this is not "while linking". Scanning binaries for linking
 errors is a step called "rev-upgrade" that MacPorts performs after every
 install or upgrade. It's designed to catch the fairly-common problem of
 someone updating a port to a new version that installs a new backwards-
 incompatible version of a library without remembering to increase the
 revision of all ports that link with that library, which renders those
 ports that link with the older library broken. If the new library is a
 different major version than the old one, then programs linking with the
 older library cannot be launched anymore. Instead, you get a message that
 the library can't be found. In the case of CoreImage here, it's only the
 minor library version that has changed; the major version ("A") hasn't so
 you won't get a file not found error when using programs that link with
 the library, but it is expected that you would see other problems, so it
 is reported to you.

 > However, `otool` reports version 1.0.1:
 >
 > {{{
 > ❯ otool -L $(which ffmpeg) | grep -i coreimage
 >
 /System/Library/Frameworks/CoreImage.framework/Versions/A/CoreImage
 (compatibility version 1.0.1, current version 6.0.0)
 > }}}

 Precisely. ffmpeg et al indicate that they require CoreImage compatibility
 version 1.0.1 or later. This version of CoreImage is what the macOS SDK on
 the machine that built this ffmpeg claims the OS has. Rev-upgrade is
 noticing that the OS actually has CoreImage compatibility version 1.0.0
 and notifies you, since that combination is not expected to work.

 > And at least ffmpeg, ffprobe and ffplay seem to work fine.

 Oh! That's new information. I assumed ffmpeg et al would not launch. But
 it works? Is that true for everyone following this ticket?

 I have observed before that macOS doesn't actually inspect minor library
 minor versions as much as I would have expected when running programs,
 which leads to another fairly common problem of projects publishing
 incorrectly versioned libraries without realizing that they have done so.
 This often happens when projects switch from one build system (e.g.
 autotools with libtool) to another (e.g. cmake or meson) without
 understanding the intricacies of library versioning on every platform,
 especially on macOS where libtool's library versioning differs from Linux
 for historical reasons.

 But the fact that macOS doesn't check the minor library version isn't a
 valid excuse for publishing libraries with incorrect minor versioning
 information, so the OCLP developers should still correct this mistake so
 that software that does check the minor library versioning, like MacPorts'
 rev-upgrade feature, don't complain.

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