Building from source seems to have worked: Sellotape:~ mnewman$ port -v installed ffmpeg The following ports are currently installed: ffmpeg @4.4.4_8+gpl2 (active) requested_variants='' platform='darwin 24' archs='x86_64' date='2024-10-03T12:05:08+0700’
I will do my best to file a report with Apple. Thanks for the help. > On Oct 3, 2024, at 11:14, Ryan Carsten Schmidt <[email protected]> > wrote: > > On Oct 2, 2024, at 22:28, Michael Newman wrote: >> >> Sellotape:bin mnewman$ file /opt/local/lib/libavcodec.58.dylib >> /opt/local/lib/libavcodec.58.134.100.dylib >> /opt/local/lib/libavcodec.58.dylib: data >> /opt/local/lib/libavcodec.58.134.100.dylib: data >> >> Unfortunately, I don’t recall if ffmpeg was built from source or via binary. >> Sorry. >> >> This on a 2019 Intel iMac upgraded to Sequoia (15.0) just two days ago. > > I can confirm this problem in the ffmpeg archive we produced on our macOS 15 > x86_64 build machine. > > Large portions of that dylib file, including the beginning that allow the > file command to identify what it is, are null bytes. The file has been > corrupted. > > As far as I know, this is a bug in the APFS filesystem. The problem goes back > to macOS 10.15 at least but we only learned about it more recently. > > Our ticket on this is https://trac.macports.org/ticket/67336. My Apple > Feedback report about this is FB12160429. Apple has never acknowledged it or > responded to it. Summarizing: > > What happens is that the filesystem keeps track of which regions in a file > are nulls ("holes") and represents the file sparsely so that those holes > don't actually take up disk space. When we use tar to create an archive of > files installed by a port, tar learns from the filesystem about those holes > and also represents them sparsely in the archive, excluding those sections of > the file from the archive, since they're supposed to be nulls. The bug is > that the filesystem tells tar there are holes when in fact those holes had > already been filled with data and should not be excluded, but there's no way > for tar to know that the filesystem is lying. > > We have a workaround we can employ for root MacPorts installations (run > /usr/sbin/purge before creating the tar archive to clear the filesystem > cache) but we haven't implemented it in MacPorts base because we don't know a > solution for non-root MacPorts installations. This fix has only been > implemented manually in one port (pari). I had thought to write a PortGroup > that could be included in affected ports, but there's no reason why only > specific ports should be affected. It could affect any port and any file. > > BSD tar 3.6.0 and later can be told not to represent files sparsely which > would work around the bug but even in macOS 15 Apple includes an older > version of BSD tar than that. GNU tar can be told whether to represent files > sparsely, and doesn't by default, but GNU tar isn't included in any macOS > versions that support APFS. > > I could increase the revision of the ffmpeg port to rebuild it and make a new > archive but there is no guarantee that the problem would not strike again, on > any of the builders using the APFS filesystem. > > For now, you can rebuild ffmpeg from source and hope that the issue does not > occur on your machine: > > sudo port -ns upgrade --force ffmpeg > > Apple pays more attention to issues that affect more users, measured by how > many duplicates a bug has. If this problem affects you please file a bug > report with Apple and reference my 2023 bug number FB12160429 and the 2019 > bug FB7378125 that I believe it's a duplicate of so that they can mark your > bug as a duplicate and hopefully see how big a problem this is and start > working on a fix. > > https://feedbackassistant.apple.com/ > >
smime.p7s
Description: S/MIME cryptographic signature
