Opened 7 weeks ago

Last modified 4 weeks ago

#70882 assigned defect

OpenCore Legacy Patcher 2.0.2 installs faulty CoreImage framework on macOS 15 on Macs using 3802-based GPUs

Reported by: RivetBenoit (Benoit Rivet) Owned by:
Priority: Normal Milestone:
Component: ports Version: 2.10.1
Keywords: sequoia Cc: kampfflunder, ednl (Ewoud Dronkert), michaelnaumann (Michael Naumann)
Port: ffmpeg, ffmpeg6, ffmpeg7, ffmpeg-devel

Description

After installing ffmpeg and ffmpeg7 on Mac OS Sequoia (i386), there are linking errors : 

--->  Updating database of binaries
--->  Scanning binaries for linking errors
--->  Found 10 broken files, matching files to ports     
--->  Found 2 broken ports, determining rebuild order
You can always run 'port rev-upgrade' again to fix errors.
The following ports will be rebuilt:
 ffmpeg7 @7.0.2+gpl2
 ffmpeg @4.4.4+gpl2

Rebuilding the ports does not fix the linking errors

Attachments (1)

OpenCoreLegacyPatcher.log​ (23.7 KB) - added by RivetBenoit (Benoit Rivet) 5 weeks ago.
Files installed by OpenCore Legay Patcher

Download all attachments as: .zip

Change History (35)

comment:1 Changed 7 weeks ago by jmroot (Joshua Root)

Cc: dbevans jeremyhu barracuda156 added
Keywords: Linking errors removed
Owner: set to mascguy
Status: new → assigned

Can you please show more verbose output, e.g. from sudo port -d -y rev-upgrade?

comment:2 Changed 7 weeks ago by RivetBenoit (Benoit Rivet)

Well, it seems that /System/Library/Frameworks/CoreImage.framework/Versions/A/CoreImage provides version 1.0.0 but /opt/local/libexec/ffmpeg7/lib/libavfilter.10.1.100.dylib requires version 1.0.1 or later.

I installed Mac OS Sequoia on an unsupported MacMini 2012 using ​https://dortania.github.io/OpenCore-Legacy-Patcher/. The OpenCore Patcher may have installed CoreImage version 1.0.0 instead of whichever version is installed for the supported i386 Mac, but I don't know how to check whether that is the case. Strangely enough, there was no linking error with Mac OS Sonoma as installed using OpenCore Legacy Patcher. 

sudo port -d -y rev-upgrade
Password:
DEBUG: Copying /Users/benoit/Library/Preferences/com.apple.dt.Xcode.plist to /opt/local/var/macports/home/Library/Preferences
--->  Scanning binaries for linking errors
DEBUG: skipping ppc in /opt/local/libexec/cmake-bootstrap/share/cmake-3.9/Modules/CPack.OSXScriptLauncher.in since this system can't run it anyway
DEBUG: Ignoring loadcommand containing @rpath in /opt/local/libexec/llvm-18/bin/bugpoint
DEBUG: Ignoring loadcommand containing @rpath in /opt/local/libexec/llvm-18/bin/dsymutil
DEBUG: Ignoring loadcommand containing @rpath in /opt/local/libexec/llvm-18/bin/llc
DEBUG: Ignoring loadcommand containing @rpath in /opt/local/libexec/llvm-18/bin/lli
DEBUG: Ignoring loadcommand containing @rpath in /opt/local/libexec/llvm-18/bin/llvm-ar
DEBUG: Ignoring loadcommand containing @rpath in /opt/local/libexec/llvm-18/bin/llvm-as
DEBUG: Ignoring loadcommand containing @rpath in /opt/local/libexec/llvm-18/bin/llvm-bcanalyzer
DEBUG: Ignoring loadcommand containing @rpath in /opt/local/libexec/llvm-18/bin/llvm-c-test
DEBUG: Ignoring loadcommand containing @rpath in /opt/local/libexec/llvm-18/bin/llvm-cat
DEBUG: Ignoring loadcommand containing @rpath in /opt/local/libexec/llvm-18/bin/llvm-cfi-verify
DEBUG: Ignoring loadcommand containing @rpath in /opt/local/libexec/llvm-18/bin/llvm-cov
DEBUG: Ignoring loadcommand containing @rpath in /opt/local/libexec/llvm-18/bin/llvm-cvtres
DEBUG: Ignoring loadcommand containing @rpath in /opt/local/libexec/llvm-18/bin/llvm-cxxdump
DEBUG: Ignoring loadcommand containing @rpath in /opt/local/libexec/llvm-18/bin/llvm-cxxfilt
DEBUG: Ignoring loadcommand containing @rpath in /opt/local/libexec/llvm-18/bin/llvm-cxxmap
DEBUG: Ignoring loadcommand containing @rpath in /opt/local/libexec/llvm-18/bin/llvm-debuginfo-analyzer
DEBUG: Ignoring loadcommand containing @rpath in /opt/local/libexec/llvm-18/bin/llvm-debuginfod
DEBUG: Ignoring loadcommand containing @rpath in /opt/local/libexec/llvm-18/bin/llvm-debuginfod-find
DEBUG: Ignoring loadcommand containing @rpath in /opt/local/libexec/llvm-18/bin/llvm-diff
DEBUG: Ignoring loadcommand containing @rpath in /opt/local/libexec/llvm-18/bin/llvm-dis
DEBUG: Ignoring loadcommand containing @rpath in /opt/local/libexec/llvm-18/bin/llvm-dwarfdump
DEBUG: Ignoring loadcommand containing @rpath in /opt/local/libexec/llvm-18/bin/llvm-dwarfutil
DEBUG: Ignoring loadcommand containing @rpath in /opt/local/libexec/llvm-18/bin/llvm-dwp
DEBUG: Ignoring loadcommand containing @rpath in /opt/local/libexec/llvm-18/bin/llvm-extract
DEBUG: Ignoring loadcommand containing @rpath in /opt/local/libexec/llvm-18/bin/llvm-gsymutil
DEBUG: Ignoring loadcommand containing @rpath in /opt/local/libexec/llvm-18/bin/llvm-ifs
DEBUG: Ignoring loadcommand containing @rpath in /opt/local/libexec/llvm-18/bin/llvm-jitlink
DEBUG: Ignoring loadcommand containing @rpath in /opt/local/libexec/llvm-18/bin/llvm-libtool-darwin
DEBUG: Ignoring loadcommand containing @rpath in /opt/local/libexec/llvm-18/bin/llvm-link
DEBUG: Ignoring loadcommand containing @rpath in /opt/local/libexec/llvm-18/bin/llvm-lipo
DEBUG: Ignoring loadcommand containing @rpath in /opt/local/libexec/llvm-18/bin/llvm-lto
DEBUG: Ignoring loadcommand containing @rpath in /opt/local/libexec/llvm-18/bin/llvm-lto2
DEBUG: Ignoring loadcommand containing @rpath in /opt/local/libexec/llvm-18/bin/llvm-mc
DEBUG: Ignoring loadcommand containing @rpath in /opt/local/libexec/llvm-18/bin/llvm-mca
DEBUG: Ignoring loadcommand containing @rpath in /opt/local/libexec/llvm-18/bin/llvm-ml
DEBUG: Ignoring loadcommand containing @rpath in /opt/local/libexec/llvm-18/bin/llvm-modextract
DEBUG: Ignoring loadcommand containing @rpath in /opt/local/libexec/llvm-18/bin/llvm-mt
DEBUG: Ignoring loadcommand containing @rpath in /opt/local/libexec/llvm-18/bin/llvm-nm
DEBUG: Ignoring loadcommand containing @rpath in /opt/local/libexec/llvm-18/bin/llvm-objcopy
DEBUG: Ignoring loadcommand containing @rpath in /opt/local/libexec/llvm-18/bin/llvm-objdump
DEBUG: Ignoring loadcommand containing @rpath in /opt/local/libexec/llvm-18/bin/llvm-opt-report
DEBUG: Ignoring loadcommand containing @rpath in /opt/local/libexec/llvm-18/bin/llvm-pdbutil
DEBUG: Ignoring loadcommand containing @rpath in /opt/local/libexec/llvm-18/bin/llvm-profdata
DEBUG: Ignoring loadcommand containing @rpath in /opt/local/libexec/llvm-18/bin/llvm-profgen
DEBUG: Ignoring loadcommand containing @rpath in /opt/local/libexec/llvm-18/bin/llvm-rc
DEBUG: Ignoring loadcommand containing @rpath in /opt/local/libexec/llvm-18/bin/llvm-readobj
DEBUG: Ignoring loadcommand containing @rpath in /opt/local/libexec/llvm-18/bin/llvm-readtapi
DEBUG: Ignoring loadcommand containing @rpath in /opt/local/libexec/llvm-18/bin/llvm-reduce
DEBUG: Ignoring loadcommand containing @rpath in /opt/local/libexec/llvm-18/bin/llvm-remarkutil
DEBUG: Ignoring loadcommand containing @rpath in /opt/local/libexec/llvm-18/bin/llvm-rtdyld
DEBUG: Ignoring loadcommand containing @rpath in /opt/local/libexec/llvm-18/bin/llvm-sim
DEBUG: Ignoring loadcommand containing @rpath in /opt/local/libexec/llvm-18/bin/llvm-size
DEBUG: Ignoring loadcommand containing @rpath in /opt/local/libexec/llvm-18/bin/llvm-split
DEBUG: Ignoring loadcommand containing @rpath in /opt/local/libexec/llvm-18/bin/llvm-stress
DEBUG: Ignoring loadcommand containing @rpath in /opt/local/libexec/llvm-18/bin/llvm-strings
DEBUG: Ignoring loadcommand containing @rpath in /opt/local/libexec/llvm-18/bin/llvm-symbolizer
DEBUG: Ignoring loadcommand containing @rpath in /opt/local/libexec/llvm-18/bin/llvm-tli-checker
DEBUG: Ignoring loadcommand containing @rpath in /opt/local/libexec/llvm-18/bin/llvm-undname
DEBUG: Ignoring loadcommand containing @rpath in /opt/local/libexec/llvm-18/bin/llvm-xray
DEBUG: Ignoring loadcommand containing @rpath in /opt/local/libexec/llvm-18/bin/opt
DEBUG: Ignoring loadcommand containing @rpath in /opt/local/libexec/llvm-18/bin/sancov
DEBUG: Ignoring loadcommand containing @rpath in /opt/local/libexec/llvm-18/bin/sanstats
DEBUG: Ignoring loadcommand containing @rpath in /opt/local/libexec/llvm-18/bin/verify-uselistorder
DEBUG: Ignoring loadcommand containing @rpath in /opt/local/libexec/llvm-18/lib/libLTO.dylib
DEBUG: Ignoring loadcommand containing @rpath in /opt/local/libexec/llvm-18/lib/libRemarks.dylib
DEBUG: Skipping weakly-linked /System/Library/Frameworks/Metal.framework/Versions/A/Metal
DEBUG: Skipping weakly-linked /System/Library/Frameworks/QuartzCore.framework/Versions/A/QuartzCore
DEBUG: Skipping weakly-linked /System/Library/Frameworks/GameController.framework/Versions/A/GameController
DEBUG: Skipping weakly-linked /System/Library/Frameworks/CoreHaptics.framework/Versions/A/CoreHaptics
DEBUG: Ignoring loadcommand containing @rpath in /opt/local/bin/cargo-clippy
DEBUG: Ignoring loadcommand containing @rpath in /opt/local/bin/cargo-clippy
DEBUG: Ignoring loadcommand containing @rpath in /opt/local/bin/clippy-driver
DEBUG: Ignoring loadcommand containing @rpath in /opt/local/bin/clippy-driver
DEBUG: Ignoring loadcommand containing @rpath in /opt/local/bin/rustc
DEBUG: Ignoring loadcommand containing @rpath in /opt/local/bin/rustc
DEBUG: Ignoring loadcommand containing @rpath in /opt/local/bin/rustdoc
DEBUG: Ignoring loadcommand containing @rpath in /opt/local/bin/rustdoc
DEBUG: Ignoring loadcommand containing @rpath in /opt/local/bin/rustfmt
DEBUG: Ignoring loadcommand containing @rpath in /opt/local/bin/rustfmt
DEBUG: Ignoring loadcommand containing @rpath in /opt/local/lib/librustc_driver-297e0216208a905e.dylib
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
DEBUG: Marking /opt/local/bin/ffmpeg as broken
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
DEBUG: Marking /opt/local/bin/ffplay as broken
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
DEBUG: Marking /opt/local/bin/ffprobe as broken
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
DEBUG: Marking /opt/local/lib/libavdevice.58.13.100.dylib as broken
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
DEBUG: Marking /opt/local/lib/libavfilter.7.110.100.dylib as broken
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
DEBUG: Marking /opt/local/libexec/ffmpeg7/bin/ffmpeg7 as broken
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
DEBUG: Marking /opt/local/libexec/ffmpeg7/bin/ffplay7 as broken
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
DEBUG: Marking /opt/local/libexec/ffmpeg7/bin/ffprobe7 as broken
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
DEBUG: Marking /opt/local/libexec/ffmpeg7/lib/libavdevice.61.1.100.dylib as broken
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
DEBUG: Marking /opt/local/libexec/ffmpeg7/lib/libavfilter.10.1.100.dylib as broken
--->  Found 10 broken files, matching files to ports
--->  Found 2 broken ports, determining rebuild order
DEBUG: Broken: ffmpeg
DEBUG: Broken: ffmpeg7
DEBUG: Processing port ffmpeg @1:4.4.4_8+gpl2
DEBUG: Processing port yt-dlp @0:2024.08.06_0+ffmpeg+python312
DEBUG: Processing port ffmpeg7 @0:7.0.2_0+gpl2
You can always run 'port rev-upgrade' again to fix errors.
The following ports will be rebuilt:
 ffmpeg @4.4.4+gpl2
 ffmpeg7 @7.0.2+gpl2
Last edited 7 weeks ago by RivetBenoit (Benoit Rivet) (previous) (diff)

comment:3 Changed 7 weeks ago by ryandesign (Ryan Carsten Schmidt)

Keywords: sequoia added

Figuring out why your /System/Library/Frameworks/CoreImage.framework/Versions/A/CoreImage is version 1.0.0 and getting it updated to 1.0.1 is probably what's needed here.

The machine doing our buildbot builds for x86_64 macOS 13, 14, and 15 is a 2016 MacBook Pro running OpenCore Legacy Patcher. I suppose it's possible that OCLP is downgrading CoreImage to 1.0.0 on some systems like yours, however that would seem to be a compatibility problem. And I checked our other build machines. CoreImage first appeared in OS X 10.11 and it was already version 2.0.0 compatibility version 1.0.1 back then.

comment:4 Changed 6 weeks ago by kampfflunder

Same problem here. Imac 27" late 2014 (Imac 15,1), MacOS Sequoia 15.0.1, OCLP 2.0.2

comment:5 in reply to:  4 Changed 6 weeks ago by ryandesign (Ryan Carsten Schmidt)

Cc: kampfflunder added

Replying to ryandesign:

The machine doing our buildbot builds for x86_64 macOS 13, 14, and 15 is a 2016 MacBook Pro running OpenCore Legacy Patcher.

macOS 15 x86_64 builds are now being done on a 2018 Mac mini with no need for OCLP. I deleted our ffmpeg binary and had this machine recreate it yesterday for an unrelated reason. The newly built ffmpeg still links with CoreImage compatibility version 1.0.1, current version 6.0.0.

I have a 2011 MacBook Pro with macOS 15.0 installed with OCLP and on that system ffmpeg installed from yesterday's binary works fine.

Replying to kampfflunder:

Same problem here. Imac 27" late 2014 (Imac 15,1), MacOS Sequoia 15.0.1, OCLP 2.0.2

Please confirm: if you run sudo port -d rev-upgrade, it says /System/Library/Frameworks/CoreImage.framework/Versions/A/CoreImage provides version 1.0.0? What happens if you run dyld_info -load_commands /System/Library/Frameworks/CoreImage.framework/Versions/A/CoreImage | grep -B1 -A5 LC_ID_DYLIB? On my system it says: 

Load command #4
             cmd: LC_ID_DYLIB
         cmdsize: 0x60
            name: "/System/Library/Frameworks/CoreImage.framework/Versions/A/CoreImage"
        cur-vers: 6.0
     compat-vers: 1.0.1
Load command #5

What does yours say for cur-vers and does your say compat-vers: 1.0.0 instead? If so, I don't know how that could work; you need compatibility version 1.0.1 for compatibility with all existing software that uses CoreImage. You may need to write to an OpenCore Legacy Patcher support forum to see if anyone knows why this has happened and how to fix it. The only fix I can think of is reinstalling macOS.

comment:6 Changed 6 weeks ago by RivetBenoit (Benoit Rivet)

sudo port -d rev-upgrade gives (among other messages) : 

/System/Library/Frameworks/CoreImage.framework/Versions/A/CoreImage provides version 1.0.0

dyld_info -load_commands /System/Library/Frameworks/CoreImage.framework/Versions/A/CoreImage | grep -B1 -A5 LC_ID_DYLIB gives : 

Load command #3
             cmd: LC_ID_DYLIB
         cmdsize: 0x60
            name: "/System/Library/Frameworks/CoreImage.framework/Versions/A/CoreImage"
        cur-vers: 1.0
     compat-vers: 1.0
Load command #4

comment:7 in reply to:  6 ; Changed 5 weeks ago by kampfflunder

Replying to RivetBenoit:

sudo port -d rev-upgrade gives (among other messages) : 

/System/Library/Frameworks/CoreImage.framework/Versions/A/CoreImage provides version 1.0.0

dyld_info -load_commands /System/Library/Frameworks/CoreImage.framework/Versions/A/CoreImage | grep -B1 -A5 LC_ID_DYLIB gives : 

Load command #3
             cmd: LC_ID_DYLIB
         cmdsize: 0x60
            name: "/System/Library/Frameworks/CoreImage.framework/Versions/A/CoreImage"
        cur-vers: 1.0
     compat-vers: 1.0
Load command #4

Exactly the same here. In case it matters: 

# md5sum /System/Library/Frameworks/CoreImage.framework/Versions/A/CoreImage
eff07dd19a5de8edfcacee84def0c159  /System/Library/Frameworks/CoreImage.framework/Versions/A/CoreImage

comment:8 Changed 5 weeks ago by ryandesign (Ryan Carsten Schmidt)

I don't think there's any way MacPorts can help with this problem. There seems to be a mistake with the way that CoreImage is installed on your Macs, and that will need to be resolved before you can use any software that uses CoreImage.

comment:9 in reply to:  7 Changed 5 weeks ago by ryandesign (Ryan Carsten Schmidt)

Replying to kampfflunder:

In case it matters: 

# md5sum /System/Library/Frameworks/CoreImage.framework/Versions/A/CoreImage
eff07dd19a5de8edfcacee84def0c159  /System/Library/Frameworks/CoreImage.framework/Versions/A/CoreImage

The result you should get on macOS 11 or later is: 

% md5sum /System/Library/Frameworks/CoreImage.framework/Versions/A/CoreImage
md5sum: /System/Library/Frameworks/CoreImage.framework/Versions/A/CoreImage: No such file or directory

All system libraries and frameworks should not exist on disk as of macOS 11; they should only be present in the dyld shared cache. If /System/Library/Frameworks/CoreImage.framework/Versions/A/CoreImage exists on disk on your macOS 11 or later system, try renaming it (e.g. to CoreImage.off) to disable it. You might check its modification date; maybe that provides a clue about when it got installed. (Does it coincide with an OS update? OS installation? OCLP update?) There might be other files on disk in /System/Library/Frameworks that don't match their dyld shared cache counterparts that shouldn't be on disk, but checking on our macOS 15 build machine, it looks like it is normal for some framework files to still be there, so I don't have a definitive command for you to run to see if you have any other files that you should disable. But if you get a similar error about some other framework being of an insufficient version, that might give you a clue of where to look next.

comment:10 Changed 5 weeks ago by ryandesign (Ryan Carsten Schmidt)

One possible explanation for this incorrect CoreImage file on your disk could be malware. It could be a proxy dylib whose purpose is to be a man-in-the-middle, thereby gaining access to the memory space of any program that links with CoreImage. In this case it does not seem like a particularly successful attempt, given the incorrect version number and the resulting error message that leads us to it. If this is malware, it may be indiscriminately replacing a whole variety of system frameworks and libraries with proxy dylibs, with the malware authors not realizing that some libraries have compatibility versions higher than 1.0.0.

Normally, System Integrity Protection prevents you or any software not from Apple from modifying system locations, but OCLP disables some of SIP's safeguards. On my 2011 MacBook Pro with macOS 15 installed using OCLP I tried creating /System/Library/Frameworks/CoreImage.framework/Versions/A/CoreImage and SIP correctly prevented it due to being a read-only filesystem. But I know that OCLP requires different fixes on different models and maybe on your models it has disabled so much of SIP that writing to system locations is allowed. Or you could have separately disabled the remaining SIP safeguards to make this possible.

If you attach the incorrect CoreImage file to this ticket we could try to determine whether it is a legitimate Apple framework or something else.

Changed 5 weeks ago by RivetBenoit (Benoit Rivet)

Attachment: OpenCoreLegacyPatcher.log​ added

Files installed by OpenCore Legay Patcher

comment:11 Changed 5 weeks ago by RivetBenoit (Benoit Rivet)

I can confirm that this is due to OpenCore Legacy Patcher. I just installed Sequoia 15.0.1 and after rebooting (without internet, since wifi does not work unless patched): 

% dyld_info -load_commands /System/Library/Frameworks/CoreImage.framework/Versions/A/CoreImage | grep -B1 -A5 LC_ID_DYLIB
Load command #4
             cmd: LC_ID_DYLIB
         cmdsize: 0x60
            name: "/System/Library/Frameworks/CoreImage.framework/Versions/A/CoreImage"
        cur-vers: 6.0
     compat-vers: 1.0.1
Load command #5

After root patching : 

% dyld_info -load_commands /System/Library/Frameworks/CoreImage.framework/Versions/A/CoreImage | grep -B1 -A5 LC_ID_DYLIB
Load command #3
             cmd: LC_ID_DYLIB
         cmdsize: 0x60
            name: "/System/Library/Frameworks/CoreImage.framework/Versions/A/CoreImage"
        cur-vers: 1.0
     compat-vers: 1.0
Load command #4

comment:12 Changed 5 weeks ago by kencu (Ken)

I don't have that file on my Sonoma Intel machine with OCLP. I haven't updated it to Sequoia as yet. 

 % ls -la /System/Library/Frameworks/CoreImage.framework/Versions/A
total 32
drwxr-xr-x    8 root  wheel    256  5 Sep 02:17 .
drwxr-xr-x    4 root  wheel    128  5 Sep 02:17 ..
-rw-r--r--    1 root  wheel  45007  5 Sep 02:17 CoreImage.metallib
drwxr-xr-x    4 root  wheel    128  5 Sep 02:17 Frameworks
drwxr-xr-x   27 root  wheel    864  5 Sep 02:17 Headers
drwxr-xr-x    3 root  wheel     96  5 Sep 02:17 Modules
drwxr-xr-x  114 root  wheel   3648  5 Sep 02:17 Resources
drwxr-xr-x    3 root  wheel     96  5 Sep 02:17 _CodeSignature

comment:13 in reply to:  12 Changed 5 weeks ago by ryandesign (Ryan Carsten Schmidt)

Replying to RivetBenoit:

I can confirm that this is due to OpenCore Legacy Patcher.

Ok, good to know. At least it's not malware! At this point you'll have to work with the OCLP community to resolve this.

comment:14 Changed 5 weeks ago by kencu (Ken)

Well -- maybe but I just upgraded my MacPro to Sequoia using OCLP, and I still don't have that file (just like it doesn't exist on any other current systems): 

% uname -a
Darwin Kens-Mac-Pro 24.0.0 Darwin Kernel Version 24.0.0: Tue Sep 24 23:36:30 PDT 2024; root:xnu-11215.1.12~1/RELEASE_X86_64 x86_64


% ls -la /System/Library/Frameworks/CoreImage.framework/Versions/A
total 32
drwxr-xr-x    8 root  wheel    256 30 Sep 21:10 .
drwxr-xr-x    4 root  wheel    128 30 Sep 21:10 ..
-rw-r--r--    1 root  wheel  46932 30 Sep 21:10 CoreImage.metallib
drwxr-xr-x    4 root  wheel    128 30 Sep 21:10 Frameworks
drwxr-xr-x   27 root  wheel    864 30 Sep 21:10 Headers
drwxr-xr-x    3 root  wheel     96 30 Sep 21:10 Modules
drwxr-xr-x  118 root  wheel   3776 30 Sep 21:10 Resources
drwxr-xr-x    3 root  wheel     96 30 Sep 21:10 _CodeSignature

as far as I can see, this file should not exist at all on your system: 

/System/Library/Frameworks/CoreImage.framework/Versions/A/CoreImage

what does this show, on your system?: 

ls -la /System/Library/Frameworks/CoreImage.framework/Versions/A

comment:15 Changed 5 weeks ago by ryandesign (Ryan Carsten Schmidt)

Ken, OCLP applies different patches to different Mac models. Your Mac, and mine, evidently don't need a CoreImage patch, but these users' Macs evidently do.

comment:16 Changed 5 weeks ago by kencu (Ken)

I realize that, however I can think of no scenario where this file exists 

/System/Library/Frameworks/CoreImage.framework/Versions/A/CoreImage

after installing Sequoia, before root patching, as they described above.

And I suspect something is off with the user’s system, not OCLP.

comment:17 Changed 5 weeks ago by ednl (Ewoud Dronkert)

Same problem as Benoit here on an iMac14,2 (Late 2013) with Sequoia 15.0.1 and OCLP 2.0.2. Maybe the prebuilt download would work, but I want the +nonfree variant so I have to build it myself, and that fails as outlined above.

Last edited 5 weeks ago by ednl (Ewoud Dronkert) (previous) (diff)

comment:18 in reply to:  16 ; Changed 5 weeks ago by ryandesign (Ryan Carsten Schmidt)

Replying to kencu:

I realize that, however I can think of no scenario where this file exists 

/System/Library/Frameworks/CoreImage.framework/Versions/A/CoreImage

after installing Sequoia, before root patching, as they described above.

Nobody said the file existed on disk before root patching.

dyld_info gets its information from the dyld shared cache, not from dylibs on disk. That's why I gave examples using that program, rather than otool which only reads dylibs on disk.

Last edited 5 weeks ago by ryandesign (Ryan Carsten Schmidt) (previous) (diff)

comment:19 in reply to:  17 Changed 5 weeks ago by ryandesign (Ryan Carsten Schmidt)

Cc: ednl added

Replying to ednl:

Maybe the prebuilt download would work, but I want the +nonfree variant so I have to build it myself, and that fails as outlined above.

You can try it, but the prebuilt ffmpeg archive using just its standard +gpl2 variant was built on a Mac having CoreImage compatibility version 1.0.1, so it can't work on your systems that have this rogue 1.0 version of CoreImage. That's what I believe is described above, and the solution has to come from whoever installed this CoreImage 1.0, which so far we presume to be the root patching part of OpenCore Legacy Patcher. If any of you communicate with that community and learn anything more about this, let us know.

I assumed building from source on your system might work, but you're saying even that doesn't work? If so, what error do you get? If it fails to build, can you attach the main.log?

comment:20 in reply to:  18 ; Changed 5 weeks ago by kencu (Ken)

Replying to ryandesign:

Nobody said the file existed on disk before root patching.

Ah -- but he does say it existed before root patching: comment:11

Anyone, none of my systems show this, and I have a lot of them. But with no more information coming, even the simplest "ls -la", I leave you all to it :>

Last edited 4 weeks ago by ryandesign (Ryan Carsten Schmidt) (previous) (diff)

comment:21 Changed 4 weeks ago by michaelnaumann (Michael Naumann)

Same issue here on a MacBookPro11,1 with macOS 15.0.1

sudo port -d -y rev-upgrade gives 

[...] 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
DEBUG: Marking /opt/local/libexec/ffmpeg7/lib/libavfilter.10.1.100.dylib as broken [...]
The following ports will be rebuilt: ffmpeg7 @7.0.2+gpl2+nonfree

Unfortunately only contributors to OCLP can submit bug reports.

Last edited 4 weeks ago by ryandesign (Ryan Carsten Schmidt) (previous) (diff)

comment:22 in reply to:  20 ; Changed 4 weeks ago by ryandesign (Ryan Carsten Schmidt)

Replying to kencu:

Replying to ryandesign:

Nobody said the file existed on disk before root patching.

Ah -- but he does say it existed before root patching: comment:11

Please re-read that comment. It does not say that. It shows the output of dyld_info before and after. dyld_info knows to look in the shared library cache; it does not require the library to exist on disk and does not tell us whether the library existed on disk.

none of my systems show this, and I have a lot of them.

Yes, none of mine do either. It just means that our Mac models are not affected by this OCLP bug.

Last edited 4 weeks ago by ryandesign (Ryan Carsten Schmidt) (previous) (diff)

comment:23 in reply to:  21 Changed 4 weeks ago by ryandesign (Ryan Carsten Schmidt)

Cc: michaelnaumann added

Replying to michaelnaumann:

Unfortunately only contributors to OCLP can submit bug reports.

Unfortunately, nobody here can fix problems with your operating system caused by OCLP. Affected users will need to contact OCLP developers or support communities for assistance.

Last edited 4 weeks ago by ryandesign (Ryan Carsten Schmidt) (previous) (diff)

comment:24 Changed 4 weeks ago by ryandesign (Ryan Carsten Schmidt)

The changes for ​OCLP 2.0.2 include this occurrence of "CoreImage", which could be the cause of the problem:

Resolve CoreImage crashes on 3802-based GPUs running macOS Sequoia

​This OCLP issue identifies which models use 3802-based GPUs:

Intel Ivy Bridge

# Applicable Models:
MacBookAir5,x
MacBookPro9,x
MacBookPro10,x
iMac13,x
Macmini6,x

Intel Haswell

# Applicable Models:
MacBookAir6,x
MacBookPro11,x
iMac14,x
iMac15,1 (internal, headless iGPU)
Macmini7,1

Nvidia Kepler

# Applicable Models:
MacBookPro9,1
MacBookPro10,1
MacBookPro11,3
iMac13,x
iMac14,x

RivetBenoit said they are using a 2012 Mac mini, which is on the list (Macmini6,x).

kampfflunder said they are using a late 2014 27" iMac15,1, which is on the list.

ednl said they are using a late 2013 iMac14,2 which is on the list.

michaelnaumann said they are using a MacBookPro11,1, which is on the list.

My Macs which don't experience the issue are a 2012 15" MacBook Pro (MacBookPro10,1) which, although it is on the list, is still running macOS 12 with OCLP 1.5.0 so it does not have this CoreImage patch; a 2011 13" MacBook Pro (MacBookPro8,x) which is not on the list; and a 2016 15" MacBook Pro (MacBookPro13,3) (the machine doing the macOS 13 and 14 x86_64 buildbot builds) which is not on the list.

Last edited 4 weeks ago by ryandesign (Ryan Carsten Schmidt) (previous) (diff)

comment:25 Changed 4 weeks ago by ryandesign (Ryan Carsten Schmidt)

Cc: dbevans jeremyhu barracuda156 removed
Owner: mascguy deleted
Port: ffmpeg6 ffmpeg-devel added
Summary: Linking errors after installing ffmpeg, ffmpeg7 → OpenCore Legacy Patcher 2.0.2 installs faulty CoreImage framework on macOS 15 on Macs using 3802-based GPUs

attachment:OpenCoreLegacyPatcher.log​ shows: 

- Installing Patchset: Metal 3802 Common Extended
- Handling Installs in: /System/Library/PrivateFrameworks/PhotosUICore.framework/Versions/A/Resources
- Handling Installs in: /System/Library/Frameworks
  - Installing: Metal.framework
  - Installing: CoreImage.framework

I assume this is where the bad CoreImage framework gets installed.

Searching OCLP code for "Metal 3802 Common Extended" I found:

​https://github.com/dortania/OpenCore-Legacy-Patcher/blob/4db2e976624ece2421b3448bc05688342b63f3b6/opencore_legacy_patcher/sys_patch/patchsets/shared_patches/metal_3802.py#L64-L68

where it says to get CoreImage files from "14.0 Beta 3-24" for macOS Sequoia and later.

I believe the source of the bad file is here:

​https://github.com/dortania/PatcherSupportPkg/tree/1cb56b28da16f22dbd38db3d2d3a389037225244/Universal-Binaries/14.0%20Beta%203-24/System/Library/Frameworks/CoreImage.framework/Versions/A

There appears to be a copy of Apple's real CoreImage library which has been renamed to CoreImageOld.dylib, and a wrapper library called CoreImage which presumably implements OCLP's fixes and also links with CoreImageOld.dylib. It is this wrapper CoreImage library that has the erroneous 1.0.0 current version and compatibility version. Maybe if the developers of OCLP change this wrapper library to have the same versioning as Apple's library (current version 6.0.0 compatibility version 1.0.1) that is all that's needed to fix the problem.

comment:26 Changed 4 weeks ago by ednl (Ewoud Dronkert)

Brilliant. In the mean time, I joined their Discord linked from the Github page. Currently in new member jail for 10 minutes. I'll ask about this issue there, with link to Ryan's comment 25. We'll see.

Edit 1: Discord link to my post: ​https://discord.com/channels/417165963327176704/1294720595715690526

Edit 2: Judging by the replies I got, I fear that OCLP contributors do not hang out on the Discord. Someone says I shouldn't compile software on a patched system. Their suggestion: "Your option is enable ssh, revert patches, log in remotely via ssh and do your MacPorts stuff. After finishing this you need to patch, again." If that is really the only solution, I would be very sad. Hopefully they're not fully understanding, and the real fix is still simply bumping the version string.

Last edited 4 weeks ago by ednl (Ewoud Dronkert) (previous) (diff)

comment:27 in reply to:  22 Changed 4 weeks ago by kencu (Ken)

Replying to ryandesign:

Yes, none of mine do either. It just means that our Mac models are not affected by this OCLP bug.

Yep, I'm convinced. Thanks for all the legwork demonstrating what the issue is.

comment:28 in reply to:  26 Changed 4 weeks ago by ryandesign (Ryan Carsten Schmidt)

I haven't checked your Discord link but:

Replying to ednl:

Someone says I shouldn't compile software on a patched system. Their suggestion: "Your option is enable ssh, revert patches, log in remotely via ssh and do your MacPorts stuff. After finishing this you need to patch, again."

That sounds ridiculous to me.

comment:29 Changed 4 weeks ago by ryandesign (Ryan Carsten Schmidt)

To elaborate, it is ridiculous because the problem as I understand it is not compiling software; the problem is running any program that uses CoreImage that was compiled on anyone else's system.

You claimed in comment:17 that compiling on your system also did not work but the log I requested in comment:19 was not provided so I don't know what the cause of that was.

comment:30 Changed 4 weeks ago by ryandesign (Ryan Carsten Schmidt)

I would guess that compiling something on a system with the "bad" OCLP 2.0.2 CoreImage would work "fine" because the system libraries and frameworks aren't involved in that. Instead, anything you compile would be linked against the .tbd (text-based description) files in the macOS SDK, and those would still describe the correct version 6.0.0 / compatibility version 1.0.1 CoreImage. And trying to run the resulting program would fail just as running a CoreImage-using program compiled by anyone else would fail.

Are you able to run any Apple apps that use CoreImage? I believe that would include Books, Freeform, Maps, Music, News, Photo Booth, Photos, QuickTime Player, and TV.

comment:31 Changed 4 weeks ago by 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

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)

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

comment:32 in reply to:  31 ; Changed 4 weeks ago by ryandesign (Ryan Carsten Schmidt)

Replying to 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.

comment:33 in reply to:  32 ; Changed 4 weeks ago by kampfflunder

Replying to ryandesign:

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?

Ah, I noticed that the +nonfree crashes: While the "regular" variant is fine: 

❯ ffmpeg
ffmpeg version 4.4.4 Copyright (c) 2000-2023 the FFmpeg developers
  built with Apple clang version 16.0.0 (clang-1600.0.26.3)
  configuration: --prefix=/opt/local --cc=/usr/bin/clang --mandir=/opt/local/share/man --enable-audiotoolbox --disable-indev=jack --disable-libjack --disable-libopencore-amrnb --disable-libopencore-amrwb --disable-libxcb --disable-libxcb-shm --disable-libxcb-xfixes --enable-opencl --disable-outdev=xv --enable-sdl2 --disable-securetransport --enable-videotoolbox --enable-avfilter --enable-avresample --enable-fontconfig --enable-gnutls --enable-libass --enable-libbluray --enable-libdav1d --enable-libfreetype --enable-libfribidi --enable-libmodplug --enable-libmp3lame --enable-libopenjpeg --enable-libopus --enable-librsvg --enable-libsoxr --enable-libspeex --enable-libtheora --enable-libvorbis --enable-libvpx --enable-libwebp --enable-libzimg --enable-libzvbi --enable-lzma --enable-pthreads --enable-shared --enable-swscale --enable-zlib --enable-libaom --enable-libsvtav1 --arch=x86_64 --enable-x86asm --enable-gpl --enable-libvidstab --enable-libx264 --enable-libx265 --enable-libxvid --enable-postproc
  libavutil      56. 70.100 / 56. 70.100
  libavcodec     58.134.100 / 58.134.100
  libavformat    58. 76.100 / 58. 76.100
  libavdevice    58. 13.100 / 58. 13.100
  libavfilter     7.110.100 /  7.110.100
  libavresample   4.  0.  0 /  4.  0.  0
  libswscale      5.  9.100 /  5.  9.100
  libswresample   3.  9.100 /  3.  9.100
  libpostproc    55.  9.100 / 55.  9.100
Hyper fast Audio and Video encoder
usage: ffmpeg [options] [[infile options] -i infile]... {[outfile options] outfile}...

Use -h to get full help or, even better, run 'man ffmpeg'

While +nonfree crashes: 

❯ ffmpeg
dyld[28367]: Library not loaded: /opt/local/lib/libavcodec.58.dylib
  Referenced from: <8FAB48B7-BAF9-32FA-88C8-7D23395C3792> /opt/local/bin/ffmpeg
  Reason: tried: '/opt/local/lib/libavcodec.58.dylib' (not a mach-o file), '/System/Volumes/Preboot/Cryptexes/OS/opt/local/lib/libavcodec.58.dylib' (no such file), '/opt/local/lib/libavcodec.58.dylib' (not a mach-o file), '/opt/local/lib/libavcodec.58.134.100.dylib' (not a mach-o file), '/System/Volumes/Preboot/Cryptexes/OS/opt/local/lib/libavcodec.58.134.100.dylib' (no such file), '/opt/local/lib/libavcodec.58.134.100.dylib' (not a mach-o file)
[1]    28367 abort      ffmpeg

But this seems to be another problem?

comment:34 in reply to:  33 Changed 4 weeks ago by ryandesign (Ryan Carsten Schmidt)

Replying to kampfflunder:

Ah, I noticed that the +nonfree crashes:

While the "regular" variant is fine:

Probably nothing to do with variants. The "regular" set of variants are built by our buildbot infrastructure, so you probably received a binary. If our binary worked, what gets installed on your system should work.

However, when you specify non-default variants like +nonfree, you must build from source on your system.

While +nonfree crashes: 

❯ ffmpeg
dyld[28367]: Library not loaded: /opt/local/lib/libavcodec.58.dylib
  Referenced from: <8FAB48B7-BAF9-32FA-88C8-7D23395C3792> /opt/local/bin/ffmpeg
  Reason: tried: '/opt/local/lib/libavcodec.58.dylib' (not a mach-o file), '/System/Volumes/Preboot/Cryptexes/OS/opt/local/lib/libavcodec.58.dylib' (no such file), '/opt/local/lib/libavcodec.58.dylib' (not a mach-o file), '/opt/local/lib/libavcodec.58.134.100.dylib' (not a mach-o file), '/System/Volumes/Preboot/Cryptexes/OS/opt/local/lib/libavcodec.58.134.100.dylib' (no such file), '/opt/local/lib/libavcodec.58.134.100.dylib' (not a mach-o file)
[1]    28367 abort      ffmpeg

But this seems to be another problem?

This sounds like the APFS cache bug with files that have (or had) holes; see #67336. It happens seemingly at random so if you simply rebuild the port again (sudo port -ns upgrade --force ffmpeg) it might not hit you this time. It ​did affect the macOS 15 x86_64 ffmpeg binary our server produced a few weeks ago, and then on subsequent rebuilds the problem went away. Josh has committed a workaround for this problem to the latest not-yet-released macports-base so you could also build the latest macports-base from source.

Note: See TracTickets for help on using tickets.