Opened 3 months ago
Last modified 8 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)
Change History (35)
comment:1 Changed 3 months ago by jmroot (Joshua Root)
Cc: | dbevans jeremyhu barracuda156 added |
---|---|
Keywords: | Linking errors removed |
Owner: | set to mascguy |
Status: | new → assigned |
comment:2 Changed 3 months 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
comment:3 Changed 2 months 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 follow-up: 5 Changed 2 months ago by kampfflunder
Same problem here. Imac 27" late 2014 (Imac 15,1), MacOS Sequoia 15.0.1, OCLP 2.0.2
comment:5 Changed 2 months 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 follow-up: 7 Changed 2 months 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 follow-up: 9 Changed 2 months 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 2 months 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 Changed 2 months 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 2 months 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 2 months ago by RivetBenoit (Benoit Rivet)
Attachment: | OpenCoreLegacyPatcher.log added |
---|
Files installed by OpenCore Legay Patcher
comment:11 Changed 2 months 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 follow-up: 13 Changed 2 months 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 Changed 2 months 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 2 months 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 2 months 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 follow-up: 18 Changed 2 months 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 follow-up: 19 Changed 2 months 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.
comment:18 follow-up: 20 Changed 2 months 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/CoreImageafter 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.
comment:19 Changed 2 months 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 follow-up: 22 Changed 2 months 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 :>
comment:21 follow-up: 23 Changed 2 months 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.
comment:22 follow-up: 27 Changed 2 months 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.
comment:23 Changed 2 months 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.
comment:24 Changed 2 months 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,xIntel Haswell
# Applicable Models: MacBookAir6,x MacBookPro11,x iMac14,x iMac15,1 (internal, headless iGPU) Macmini7,1Nvidia 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.
comment:25 Changed 2 months 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:
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:
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 follow-up: 28 Changed 2 months 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.
comment:27 Changed 2 months 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 Changed 8 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 8 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 8 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 follow-up: 32 Changed 8 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 follow-up: 33 Changed 8 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 follow-up: 34 Changed 8 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 Changed 8 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 ffmpegBut 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.
Can you please show more verbose output, e.g. from
sudo port -d -y rev-upgrade
?