ffmpeg-upstream @5.1.2_4+gpl2+gpl3: broken build

[townba (Brad Town)]

Attempting to install ffmpeg-upstream +gpl3 and getting the following error:

--->  Activating ffmpeg-upstream @5.1.2_4+gpl2+gpl3
--->  Cleaning ffmpeg-upstream
--->  Scanning binaries for linking errors
--->  Found 7 broken files, matching files to ports
Error: Port ffmpeg-upstream is still broken after rebuilding it more than 3 times.
Error: Please run port -d -y rev-upgrade and use the output to report a bug.
Error: rev-upgrade failed: Port ffmpeg-upstream still broken after rebuilding 3 times
Error: Follow https://guide.macports.org/#project.tickets if you believe there is a bug.

[townba (Brad Town)]

Output of sudo port -d -y rev-upgrade

[townba (Brad Town)]

Output of uname -a:

Darwin Brads-MBP.localdomain 22.4.0 Darwin Kernel Version 22.4.0: Mon Mar  6 20:59:58 PST 2023; root:xnu-8796.101.5~3/RELEASE_ARM64_T6020 arm64 arm Darwin

[ryandesign (Ryan Carsten Schmidt)]

The log says:

Could not open /opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_multimedia_ffmpeg-upstream/ffmpeg-upstream/work/destroot/opt/local/lib/libavfilter.8.dylib: Error opening or reading file (referenced from /opt/local/bin/ffmpeg)
DEBUG: Marking /opt/local/bin/ffmpeg as broken
Could not open /opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_multimedia_ffmpeg-upstream/ffmpeg-upstream/work/destroot/opt/local/lib/libavdevice.59.dylib: Error opening or reading file (referenced from /opt/local/bin/ffmpeg)
DEBUG: Marking /opt/local/bin/ffmpeg as broken
DEBUG: Marking /opt/local/bin/ffplay as broken
DEBUG: Marking /opt/local/bin/ffplay as broken
DEBUG: Marking /opt/local/bin/ffprobe as broken
DEBUG: Marking /opt/local/bin/ffprobe as broken
DEBUG: Marking /opt/local/lib/libavdevice.59.7.100.dylib as broken
--->  Found 7 broken files, matching files to ports
--->  Found 1 broken port, determining rebuild order

So the libraries were built with a wrong install name (one that includes the destroot path).

That doesn't appear to be the case for the binaries of ffmpeg-upstream @5.1.2_4+gpl2 that we have on the packages server.

I tried building with the +gpl3 variant on my machine and I didn't see wrong install names either.

We may need to see your main.log file from the build that resulted in these wrong install names. The log will have been deleted since the build was "successful", so you would have to re-run the build once more and use the -k flag to keep the log:

sudo port -nsk upgrade --force --no-rev-upgrade ffmpeg-upstream

After that, the main.log file should be present at:

port logfile ffmpeg-upstream

-k will also have kept the work directory. After you attach the log to this ticket, you can delete the log and work directory with:

sudo port clean ffmpeg-upstream

[townba (Brad Town)]

Attached main.log.gz.

At first I thought adding -k was making it work, but then I saw that ffmpeg and the others are still referencing the libraries in the build location. Partial otool -L /opt/local/bin/ffmpeg output:

/opt/local/bin/ffmpeg:
        /opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_multimedia_ffmpeg-upstream/ffmpeg-upstream/work/destroot/opt/local/lib/libavdevice.59.dylib (compatibility version 59.0.0, current version 59.7.100)
        /opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_multimedia_ffmpeg-upstream/ffmpeg-upstream/work/destroot/opt/local/lib/libavfilter.8.dylib (compatibility version 8.0.0, current version 8.44.100)
        /opt/local/lib/libavformat.59.dylib (compatibility version 59.0.0, current version 59.27.100)
        /opt/local/lib/libavcodec.59.dylib (compatibility version 59.0.0, current version 59.37.100)
...

The binary works until I clean because -k kept the build location. Of course, once I run sudo port clean ffmpeg-upstream, the binary stops working.

[townba (Brad Town)]

A little more info:

• The regular ffmpeg port works.
• I can fix the resulting ffmpeg-upstream binaries with the following super-fragile script:

  for bin in ffmpeg ffplay ffprobe; do
    for lib in libavdevice.60.dylib libavfilter.9.dylib; do
      sudo install_name_tool -change "/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_multimedia_ffmpeg-upstream/ffmpeg-upstream/work/destroot/opt/local/lib/${lib}" "/opt/local/lib/${lib}" "/opt/local/bin/${bin}"
    done
  done
  

[ryandesign (Ryan Carsten Schmidt)]

libavdevice.59.dylib appears to be created with the right install name in the build phase on line 6240 of your log and then recreated with the wrong install name in the destroot phase on line 6414 for some reason. Similarly libavfilter.8.dylib correctly on line 6238 and again incorrectly on line 6412.

[ryandesign (Ryan Carsten Schmidt)]

Comparing with our ​most recent log of building ffmpeg-upstream on macOS 13 on arm64, I don't see any invocations in clang during the destroot phase, which is how it should be.

So, there are at least two bugs:

1. something is causing re-linking of some libraries to happen in the destroot phase on your system
2. when linking happens in the destroot phase, $(DESTDIR) is erroneously included in the install name

Probably neither of these are specific to MacPorts and they should be reported to the developers of ffmpeg.

I note that your 5.1.2 log says:

External libraries:
appkit                  libmodplug              libvorbis
avfoundation            libmp3lame              libvpx
bzlib                   libopenjpeg             libx264
coreimage               libopus                 libx265
gnutls                  librav1e                libxvid
iconv                   librsvg                 libzimg
libaom                  libsmbclient            libzvbi
libaribb24              libsmbclient            lzma
libass                  libsoxr                 metal
libbluray               libspeex                sdl2
libfontconfig           libsvtav1               zlib
libfreetype             libtheora
libfribidi              libvidstab

While our 6.0 buildbot log says:

External libraries:
appkit                  libfribidi              libvidstab
avfoundation            libmodplug              libvorbis
bzlib                   libmp3lame              libvpx
coreimage               libopenjpeg             libx264
gnutls                  libopus                 libx265
iconv                   librav1e                libxvid
libaom                  librsvg                 libzimg
libass                  libsoxr                 libzvbi
libbluray               libspeex                lzma
libfontconfig           libsvtav1               sdl2
libfreetype             libtheora               zlib

The relevant difference may be that yours has "metal" while ours does not (although it's difficult to know for sure when comparing different versions)—maybe attach your most recent log so we can do a better comparison.

[townba (Brad Town)]

main.log.gz (2023-05-05)

[townba (Brad Town)]

I've attached the log for sudo port -s install ffmpeg-upstream. Note that I have the problem even without specifying variants (that wasn't the case before).

metal is still in my list of external libraries.

[townba (Brad Town)]

metal appears to be the problem. By default, ffmpeg's configure autodetects it. I'm guessing that it's not being enabled on buildbot (and maybe other systems that don't have this problem), but it is being enabled on mine.

I modified the ffmpeg-upstream Portfile to add --disable-metal to configure.args, and voilà! It installs and runs just fine.

[townba (Brad Town)]

In 0178b5be2b63848984a5993c1f0b68cca9b40d8c/macports-ports (master):

ffmpeg-upstream: skip building with Metal

See: #67173