Opened 10 months ago
Last modified 10 months ago
#73133 new defect
ffmpeg @4.4.6_3+gpl2+nonfree configure failure: librsvg-2.0 not found using pkg-config
| Reported by: | msrski59 | Owned by: | |
|---|---|---|---|
| Priority: | Normal | Milestone: | |
| Component: | ports | Version: | 2.11.5 |
| Keywords: | Cc: | mascguy (Christopher Nielsen), dbevans (David B. Evans), jeremyhu (Jeremy Huddleston Sequoia), ryandesign (Ryan Carsten Schmidt) | |
| Port: | ffmpeg |
Description
On Sequoia 15.7.1 with Xcode 26.0.1
These ports are installed on my system:
ffmpeg @4.4.6_2+gpl2+nonfree librsvg @2.58.5_0 yt-dlp @2025.08.27_0+ffmpeg+python313
MacPorts shows my yt-dlp as outdated and wants to upgrade to yt-dlp @2025.10.14_0.
To upgrade yt-dlp, MacPorts wants to install ffmpeg @4.4.6_3, even though the ffmpeg @4.4.6_2 on my system is not flagged as outdated.
ffmpeg @4.4.6_3 fails to build with the configuration error listed in the summary above.
So yt-dlp will not upgrade.
On my aging desktop running Monterey 12.7.6 with Xcode 14.2, yt-dlp @2025.10.14_0 peacefully coexists with ffmpeg @4.4.6_2 and librsvg @2.58.5_0.
main.log and config.log attached.
Attachments (2)
Change History (16)
Changed 10 months ago by msrski59
| Attachment: | config.log added |
|---|
Changed 10 months ago by msrski59
comment:1 Changed 10 months ago by ryandesign (Ryan Carsten Schmidt)
comment:2 follow-up: 6 Changed 10 months ago by ryandesign (Ryan Carsten Schmidt)
Replying to msrski59:
On Sequoia 15.7.1 with Xcode 26.0.1
On our Sequoia build machine we're using Xcode and CLT 16.4 and didn't see this problem, so one possible workaround is to downgrade your Xcode and/or CLT to 16.4.
To upgrade yt-dlp, MacPorts wants to install ffmpeg @4.4.6_3, even though the ffmpeg @4.4.6_2 on my system is not flagged as outdated.
The way that the revision was increased only for Xcode or CLT versions ≥ 15 is unusual and doesn't really work because the machine that generates the portindexes (which is what MacPorts looks at to know what's outdated) isn't running Xcode or CLT ≥ 15.
comment:3 Changed 10 months ago by ryandesign (Ryan Carsten Schmidt)
comment:4 Changed 10 months ago by msrski59
If the crash log it mentions at /opt/local/var/macports/build/ffmpeg-2da9f0d5/work/.home/Library/Logs/DiagnosticReports/clang_<YYYY-MM-DD-HHMMSS>_<hostname>.crash exists, can you attach it?
No joy. /opt/local/var/macports/build/ffmpeg-2da9f0d5/work/.home is empty.
comment:5 Changed 10 months ago by msrski59
On our Sequoia build machine we're using Xcode and CLT 16.4 and didn't see this problem, so one possible workaround is to downgrade your Xcode and/or CLT to 16.4.
I have a 2020 MacBook Air with an Intel chip, so it's pinned at Sequoia, otherwise I would have upgraded to macOS 26 Tahoe, and OS and Xcode would be on a level. I'm a user, not a hacker, so I didn't think twice about upgrading Xcode when the App Store indicated that Xcode 26 was available. I have never downgraded Xcode on any of my machines before, but the instructions I have looked at don't make it seem like a very hard job. Thanks for the suggestion -- I'll try this.
comment:6 follow-up: 7 Changed 10 months ago by msrski59
Replying to ryandesign:
Replying to msrski59:
On Sequoia 15.7.1 with Xcode 26.0.1
On our Sequoia build machine we're using Xcode and CLT 16.4 and didn't see this problem, so one possible workaround is to downgrade your Xcode and/or CLT to 16.4.
I have installed Xcode 16.4 and the corresponding Command Line Tools, and then run "port upgrade outdated" on my laptop. As expected, the downgraded Xcode and CLT build ffmpeg @4.4.6_3+gpl2+nonfree without issue, and that allows the upgrade of yt-dlp. Many thanks for the workaround.
That still leaves the issue of the build failure on Sequoia with Xcode 26.0.1 unresolved. I haven't opened many tickets on Trac, but I don't recall that any of them lingered this long without a response from package maintainers. I fully understand that MacPorts is a volunteer project, and that the maintainers of ffmpeg may just be busy in Real Life. How are tickets that do not draw a maintainer response handled?
comment:7 follow-up: 8 Changed 10 months ago by ryandesign (Ryan Carsten Schmidt)
Replying to msrski59:
How are tickets that do not draw a maintainer response handled?
Anyone else could handle the ticket. You could write to the mailing list to draw others' attention to the ticket.
comment:8 Changed 10 months ago by msrski59
Replying to ryandesign:
Anyone else could handle the ticket. You could write to the mailing list to draw others' attention to the ticket.
Several lists at the link, and I don't wish to commit a MacPorts faux pas. Do you mean write to the developers list to attract their attention? Or the users list which is probably also read by the developers?
comment:10 follow-up: 11 Changed 10 months ago by ryandesign (Ryan Carsten Schmidt)
You could also check if the newer ffmpeg ports have the same problem: ffmpeg6, ffmpeg7, ffmpeg8. If not, upstream may have already fixed the problem and we can backport it to the ffmpeg and ffmpeg4 ports.
comment:11 Changed 10 months ago by msrski59
Replying to ryandesign:
You could also check if the newer ffmpeg ports have the same problem: ffmpeg6, ffmpeg7, ffmpeg8. If not, upstream may have already fixed the problem and we can backport it to the ffmpeg and ffmpeg4 ports.
I just tested this. On Sequoia 15.7.1 with Xcode 26.0.1:
ffmpeg8 @8.0_1+gpl2+nonfree+vmaf builds without issue.
ffmpeg7 @7.1.2_0+gpl2+nonfree+vmaf builds without issue.
ffmpeg6 @6.1.3_0+gpl2+nonfree+vmaf builds without issue.
I take it that yt-dlp depends on vanilla ffmpeg and doesn't work with the ffmpeg? versions. I'm sure that there are good reasons why there are multiple ffmpeg packages, instead of just having ffmpeg @8.0_1.
comment:12 Changed 10 months ago by ryandesign (Ryan Carsten Schmidt)
At present yes the yt-dlp port declares a dependency on the ffmpeg port. I should probably switch it to one of the versioned ffmpeg ports, as should all other ports that depend on ffmpeg.
The reason for the versioned ports is that ffmpeg is frequently not backward-compatible.
comment:13 Changed 10 months ago by msrski59
Having been bitten by Murphy's Law frequently, I decided to run an experiment. Now that I am again running Xcode 26.0.1 on my Sequoia 15.7.1 laptop, I uninstalled the ffmpeg that I had built with Xcode/CLT 16.4 as a workaround for the initial build failure, and tried to install it again. To my surprise, I found that ffmpeg @4.4.6_3+gpl2+nonfree built without issue on my laptop. I am at loss to explain this.
I did not make the rookie mistake of filing a ticket without cleaning and trying to build again. I actually waited several days to open this ticket after encountering the issue. So I opened the ticket only after several clean-and-retry cycles. I also tried a couple of clean/build cycles after filing the ticket. Same configure error each time.
When I implemented the workaround, I deleted Xcode.app (26.0.1) and /Library/Developer/CommandLineTools. I installed Xcode 16.4 from the xip archive that I had downloaded from Apple, and the 16.4 CLT from the Apple dmg. As I reported above, I was then able to build ffmpeg @4.4.6_3+gpl2+nonfree and get yt-dlp to upgrade now that its dependency was satisfied.
I wanted to see if there were other packages that had a problem with the Sequoia/Xcode 26 combination, so I deleted Xcode 16.4 and /Library/Developer/CommandLineTools. I reinstalled Xcode 26.0.1 through the App Store and CLT 26 with xcode-select --install. So my current build environment should be identical to the one that caused the failure of ffmpeg to build in the first place. But ffmpeg no longer fails to build in this supposedly identical environment. I'll let hacker/developer/maintainer types hazard a guess as to why.
Since I can no longer reproduce the build failure that prompted me to open this ticket, I suppose that it should be closed.
comment:14 Changed 10 months ago by msrski59
Ah, wait. MacPorts recently updated itself from 2.11.5 to 2.11.6 -- that is the one relevant difference on my laptop between the time when I first encountered the configure error and now. Could this account for the difference in outcomes?

According to the config.log, clang crashed while trying to determine if librsvg is installed:
BEGIN /opt/local/var/macports/build/ffmpeg-2da9f0d5/work/.tmp/ffconf.lla0TeK1/test.c 1 #include <librsvg-2.0/librsvg/rsvg.h> 2 #include <stdint.h> 3 long check_rsvg_handle_render_cairo(void) { return (long) rsvg_handle_render_cairo; } 4 int main(void) { int ret = 0; 5 ret |= ((intptr_t)check_rsvg_handle_render_cairo) & 0xFFFF; 6 return ret; } END /opt/local/var/macports/build/ffmpeg-2da9f0d5/work/.tmp/ffconf.lla0TeK1/test.c /usr/bin/clang -I/opt/local/include -isysroot/Library/Developer/CommandLineTools/SDKs/MacOSX15.sdk -D_ISOC99_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -I$(SRC_PATH)/compat/dispatch_semaphore -DPIC -pipe -Os -DHAVE_LRINTF -Wno-deprecated-declarations -I/opt/local/include -isysroot/Library/Developer/CommandLineTools/SDKs/MacOSX15.sdk -arch x86_64 -std=c11 -Werror=partial-availability -fomit-frame-pointer -fPIC -pthread -I/opt/local/include/p11-kit-1 -I/opt/local/include/harfbuzz -I/opt/local/include/glib-2.0 -I/opt/local/lib/glib-2.0/include -I/opt/local/include/fribidi -I/opt/local/include/freetype2 -I/opt/local/include/libpng16 -I/opt/local/include/libxml2 -I/opt/local/include/freetype2 -I/opt/local/include/libpng16 -I/opt/local/include/freetype2 -I/opt/local/include/libpng16 -I/opt/local/include/freetype2 -I/opt/local/include/libpng16 -I/opt/local/include/fribidi -I/opt/local/include/openjpeg-2.5 -I/opt/local/include/opus -I/opt/local/include/opus -I/opt/local/include/librsvg-2.0 -I/opt/local/include/gdk-pixbuf-2.0 -I/opt/local/include/cairo -I/opt/local/include/glib-2.0 -I/opt/local/lib/glib-2.0/include -I/opt/local/include/pixman-1 -I/opt/local/include/freetype2 -I/opt/local/include/libpng16 -L/opt/local/lib -c -o /opt/local/var/macports/build/ffmpeg-2da9f0d5/work/.tmp/ffconf.lla0TeK1/test.o /opt/local/var/macports/build/ffmpeg-2da9f0d5/work/.tmp/ffconf.lla0TeK1/test.c clang: warning: argument unused during compilation: '-L/opt/local/lib' [-Wunused-command-line-argument] clang: error: unable to execute command: Segmentation fault: 11 clang: error: clang frontend command failed due to signal (use -v to see invocation) Apple clang version 17.0.0 (clang-1700.3.19.1) Target: x86_64-apple-darwin24.6.0 Thread model: posix InstalledDir: /Library/Developer/CommandLineTools/usr/bin clang: note: diagnostic msg: ******************** PLEASE ATTACH THE FOLLOWING FILES TO THE BUG REPORT: Preprocessed source(s) and associated run script(s) are located at: clang: note: diagnostic msg: /var/folders/8f/kwbtw_5s0tjfbs76q2zg_6dc0000gp/T/test-0cee2e.c clang: note: diagnostic msg: /var/folders/8f/kwbtw_5s0tjfbs76q2zg_6dc0000gp/T/test-0cee2e.sh clang: note: diagnostic msg: Crash backtrace is located in clang: note: diagnostic msg: /opt/local/var/macports/build/ffmpeg-2da9f0d5/work/.home/Library/Logs/DiagnosticReports/clang_<YYYY-MM-DD-HHMMSS>_<hostname>.crash clang: note: diagnostic msg: (choose the .crash file that corresponds to your crash) clang: note: diagnostic msg: ******************** ERROR: librsvg-2.0 not found using pkg-configIf the crash log it mentions at /opt/local/var/macports/build/ffmpeg-2da9f0d5/work/.home/Library/Logs/DiagnosticReports/clang_<YYYY-MM-DD-HHMMSS>_<hostname>.crash exists, can you attach it?