Opened 2 weeks ago
Last modified 35 hours ago
#70882 assigned defect
Linking errors after installing ffmpeg, ffmpeg7
| Reported by: | RivetBenoit (Benoit Rivet) | Owned by: | mascguy (Christopher Nielsen) |
|---|---|---|---|
| Priority: | Normal | Milestone: | |
| Component: | ports | Version: | 2.10.1 |
| Keywords: | sequoia | Cc: | dbevans (David B. Evans), jeremyhu (Jeremy Huddleston Sequoia), barracuda156, kampfflunder, ednl (Ewoud Dronkert) |
| Port: | ffmpeg, ffmpeg7 |
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 (21)
comment:1 Changed 2 weeks ago by jmroot (Joshua Root)
| Cc: | dbevans jeremyhu barracuda156 added |
|---|---|
| Keywords: | Linking errors removed |
| Owner: | set to mascguy |
| Status: | new → assigned |
comment:2 Changed 2 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
comment:3 Changed 2 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 follow-up: 5 Changed 6 days 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 6 days 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 6 days 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 6 days ago by kampfflunder
Replying to RivetBenoit:
sudo port -d rev-upgradegives (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_DYLIBgives :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 days 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 5 days 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 days 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 days ago by RivetBenoit (Benoit Rivet)
| Attachment: | OpenCoreLegacyPatcher.log added |
|---|
Files installed by OpenCore Legay Patcher
comment:11 Changed 5 days 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 4 days 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 4 days 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 4 days 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 4 days 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 4 days 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 37 hours 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 35 hours 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 35 hours 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 Changed 35 hours 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: https://trac.macports.org/ticket/70882#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 :>
Can you please show more verbose output, e.g. from
sudo port -d -y rev-upgrade?