ffmpeg @4.4.1_1+gpl2: ERROR: zvbi-0.2 not found using pkg-config

[evanmiller (Evan Miller)]

10.4.11

:info:configure Executing:  cd "/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_multimedia_ffmpeg/ffmpeg/work/ffmpeg-4.4.1" && ./configure --prefix=/opt/local --enable-swscale --enable-avfilter --enable-avresample --enable-libmp3lame --enable-libvorbis --enable-libopus --enable-librsvg --enable-libtheora --enable-libopenjpeg --enable-libmodplug --disable-libvpx --enable-libsoxr --enable-libspeex --enable-libass --disable-libbluray --enable-libzvbi --enable-lzma --enable-gnutls --enable-fontconfig --enable-libfreetype --enable-libfribidi --enable-zlib --disable-libjack --disable-libopencore-amrnb --disable-libopencore-amrwb --disable-libxcb --disable-libxcb-shm --disable-libxcb-xfixes --disable-indev=jack --disable-opencl --disable-outdev=xv --disable-audiotoolbox --disable-videotoolbox --disable-sdl2 --disable-securetransport --mandir=/opt/local/share/man --enable-shared --enable-pthreads --cc=/opt/local/bin/gcc-mp-7 --disable-asm --disable-filter=coreimage --disable-filter=coreimagesrc --disable-indev=avfoundation --disable-altivec --arch=ppc --enable-gpl --enable-postproc --enable-libx264 --enable-libxvid
:debug:configure system:  cd "/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_multimedia_ffmpeg/ffmpeg/work/ffmpeg-4.4.1" && ./configure --prefix=/opt/local --enable-swscale --enable-avfilter --enable-avresample --enable-libmp3lame --enable-libvorbis --enable-libopus --enable-librsvg --enable-libtheora --enable-libopenjpeg --enable-libmodplug --disable-libvpx --enable-libsoxr --enable-libspeex --enable-libass --disable-libbluray --enable-libzvbi --enable-lzma --enable-gnutls --enable-fontconfig --enable-libfreetype --enable-libfribidi --enable-zlib --disable-libjack --disable-libopencore-amrnb --disable-libopencore-amrwb --disable-libxcb --disable-libxcb-shm --disable-libxcb-xfixes --disable-indev=jack --disable-opencl --disable-outdev=xv --disable-audiotoolbox --disable-videotoolbox --disable-sdl2 --disable-securetransport --mandir=/opt/local/share/man --enable-shared --enable-pthreads --cc=/opt/local/bin/gcc-mp-7 --disable-asm --disable-filter=coreimage --disable-filter=coreimagesrc --disable-indev=avfoundation --disable-altivec --arch=ppc --enable-gpl --enable-postproc --enable-libx264 --enable-libxvid
:info:configure ERROR: zvbi-0.2 not found using pkg-config
:info:configure If you think configure made a mistake, make sure you are using the latest
:info:configure version from Git.  If the latest version fails, report the problem to the
:info:configure ffmpeg-user@ffmpeg.org mailing list or IRC #ffmpeg on irc.libera.chat.
:info:configure Include the log file "ffbuild/config.log" produced by configure as this will help
:info:configure solve the problem.

zvbi is installed and pkg-config zvbi-0.2 returns 0 so I'm not sure what's going on.

[evanmiller (Evan Miller)]

Looks like a GCC7 issue:

gcc-mp-7: error: unrecognized command line option '-R'

[mjhsieh (Mengjuei Hsieh)]

The temporary solution is

gsed -i -e 's@-R/opt/local/lib@-Wl,-rpath,/opt/local/lib@g' /opt/local/lib/pkgconfig/zvbi-0.2.pc

More attention to zvbi's configure might be needed.

[evanmiller (Evan Miller)]

In f845802fad3147266cd5e970f98f45fd5fa43424/macports-ports (master):

zvbi: fix pkg-config file on Tiger

Closes: #64212

[mjhsieh (Mengjuei Hsieh)]

Hi Evan, Can you add it to leopard too? Since leopard also has a problem with -R

[evanmiller (Evan Miller)]

Should we just --disable-rpath altogether for zvbi?

[Christopher Nielsen <mascguy@…>]

In 76d8a918e61e4b9986d1d45ba8afe25e835f38a2/macports-ports (master):

zvbi: disable rpath use for all macOS releases

• Also update gettext dep

See: #64212

[mascguy (Christopher Nielsen)]

Unfortunately it looks like ARM builds are now failing with rpath disabled. We'll see whether that also affects non-ARM builds as well. (Though zvbi did build and run just fine on my 10.13 installation. And ffmpeg is still working just fine as well.)

We may need to add additional configure arguments as well. But we'll see after the buildbots catch up.

[Christopher Nielsen <mascguy@…>]

In 96e27c89724dc6dfcb86aa99c7a5af1275b43a4d/macports-ports (master):

zvbi: disable rpath use for 10.5 and earlier
See: #64212

[ryandesign (Ryan Carsten Schmidt)]

Replying to mascguy:

Unfortunately it looks like ARM builds are now failing with rpath disabled.

What makes you think it's because rpath is disabled?

I see failures for macOS 12 arm and macOS 11 x86_64, both due to undefined libiconv symbols. Sounds more like the well-known libtool macOS 11+ bug.

I do see successful builds after your next change to re-enable rpath, but I don't understand why. I guess I don't understand rpath.

[mascguy (Christopher Nielsen)]

Replying to ryandesign:

What makes you think it's because rpath is disabled?

I see failures for macOS 12 arm and macOS 11 x86_64, both due to undefined libiconv symbols. Sounds more like the well-known libtool macOS 11+ bug.

I do see successful builds after your next change to re-enable rpath, but I don't understand why. I guess I don't understand rpath.

I don't yet understand the interaction between the rpath change and libiconv, either. Although the heads-up regarding libtool is helpful, thanks!

For now, given that the goal is simply to fix this port on 10.5 and earlier, I'm going to punt on investigating that. We may need to revisit at some point, but don't want to get too far into the weeds, either.

But if anyone has any ideas, please do share!

[kencu (Ken)]

FYI rpath works fine on 10.5, it's only missing on 10.4.

rpath - trying to keep it simple - separates the library name from it's installed path.

The library has the name @rpath/libMyName.dylib. It can be put absolutely anywhere, it does not care where it is put. You can move it around any where you want to.

The applications or other libraries that want to use that library reference it by @rpath/libMyName.dylib , so they don't care where it is either. But the issue becomes finding it, and more to the point, finding the one you wanted to find.

The system has a default set of search paths to look for @rpath libraries. /usr/local/lib, /usr/lib are the two main ones, but there are others I believe, for FrameWorks, etc. So package managers (homebrew) that put their libraries in /usr/local/lib "just work" with rpaths, because without any further fanfare, the libraries are found by dyld.

The PROBLEM comes when you want to put libraries in a non-default-search location, like /opt/local/lib. Then everything that has a library referenced by @rpath/libMyName.dylib also needs to have an rpath search path explicitly added into each executable to /opt/local/lib, otherwise they find some other library or no library.

And this becomes the issue -- it is rather hard to see which one they are finding (you need to set ENV VARS to print out the search paths being searched) ... are they finding libiconv.dylib in /usr/lib, or /opt/local/lib, or some other rpath search path that has been added by some qt5 build script or by cmake in some CMakeLists.txt, or some other method somebody modified the rpath search path.

[kencu (Ken)]

On linux, you can change the system's default rpath search path, to accommodate a distribution's installed directories.

On macOS, mortals cannot make a system-wide default rpath search change.

[mouse07410 (Mouse)]

And it is good - some applications (including Rust and Haskell) require system libiconv, so modifying system-wide rpath search works screw those up for sure.

I say - remove rpath from zvbi.

[kencu (Ken)]

The maintainer of gcc for darwin has indicated that all gcc versions (and libgcc, etc) that are still being maintained (10+ ?) are going to move to full @rpath linkage very shortly.

In essence, the maintenance burden gcc is otherwise overwhelming.

SO -- either MacPorts figures out how to love @rpaths, or learns to hack away on gcc in a post-install phase with install_name_tool.

That is not overwhelmingly hard to do, so watch for that :>

[kencu (Ken)]

rust and haskell are hard to drive. They don't of course actually require the system libiconv.

But they have to build against the same libiconv headers that match the libiconv library they plan to link against, and they are hard to bend to your will.

[mjhsieh (Mengjuei Hsieh)]

Replying to kencu:

FYI rpath works fine on 10.5, it's only missing on 10.4.

I swear that -R is broken on my 10.5 box, but -Wl,-rpath, does work on my 10.5 box

[mouse07410 (Mouse)]

rust and haskell are hard to drive.

My point was that for installations that use apps other than what OS and Macports provide, modifying the system-wide rpath could be problematic.

They don't of course actually require the system libiconv

If you want to rebuild everything from the source yourself, sure. Otherwise:

$ otool -L /Users/ur20980/.ghcup/ghc/9.2.1/lib/ghc-9.2.1/lib/x86_64-osx-ghc-9.2.1/libHSbase-4.16.0.0-ghc9.2.1.dylib
/Users/ur20980/.ghcup/ghc/9.2.1/lib/ghc-9.2.1/lib/x86_64-osx-ghc-9.2.1/libHSbase-4.16.0.0-ghc9.2.1.dylib:
	@rpath/libHSbase-4.16.0.0-ghc9.2.1.dylib (compatibility version 0.0.0, current version 0.0.0)
	/usr/lib/libiconv.2.dylib (compatibility version 7.0.0, current version 7.0.0)
	@rpath/libHSghc-bignum-1.2-ghc9.2.1.dylib (compatibility version 0.0.0, current version 0.0.0)
	@rpath/libHSghc-prim-0.8.0-ghc9.2.1.dylib (compatibility version 0.0.0, current version 0.0.0)
	/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1292.100.5)
	/usr/lib/libcharset.1.dylib (compatibility version 2.0.0, current version 2.0.0)

I want to rebuild GHC-9.2.1 (for example) from sources even less than I want to rebuild, e.g., clang or gcc. That's one reason why I use Macports instead of compiling everything myself. ;-)

But they have to build against the same libiconv headers that match the libiconv library they plan to link against, and they are hard to bend to your will.

Yes.

[kencu (Ken)]

In your case here /usr/lib/libiconv.2.dylib is hardcoded :> So modifying the system rpath search order would make absolutely no difference here. But I know you know that. (it could have just as easily been hardcoded to /opt/local/lib/libiconv.2.dylib and that would have been just fine too)

I get your underlying point though, which is the same as the point all of us have been making ... rpaths might introduce confusion in general.

[mouse07410 (Mouse)]

I get your underlying point though, which is the same as the point all of us have been making ... rpaths might introduce confusion in general

Yes.

My personal method of dealing with two libiconv versions was creating /opt/local/lib/liconv/libiconv.tbd, and pointing app builds that need linking against both Macports and system stuff to -L/opt/local/lib/liconv -liconv first. An ugly workaround, but it works...

[kencu (Ken)]

cool idea. You know, the libiconv folks go out of their way to purposefully cause this failure, by enforcing different symbol names for user and system versions of libiconv.

They must have had so many bug reports for crossed-up header/lib combos they finally said “We’ll put a stop to this!”

Kinda surprising others didn’t follow their lead!

[mouse07410 (Mouse)]

I wonder what's the purpose of the "other libiconv". I'd much prefer packages suffer with the existing system-provided libiconv (if a complex system like Haskell Base library can live with OS-provided libiconv, I'm very sure other packages can too) to this idiotic inconvenient mess with two libraries.

I'm happy with other packages that do not follow this road-to-hell.

[barracuda156]

Replying to mouse07410:

rust and haskell are hard to drive.

My point was that for installations that use apps other than what OS and Macports provide, modifying the system-wide rpath could be problematic.

They don't of course actually require the system libiconv

If you want to rebuild everything from the source yourself, sure. Otherwise:

	/usr/lib/libiconv.2.dylib (compatibility version 7.0.0, current version 7.0.0)

Any idea where exactly this is hard-coded? I have a problem now installing ghc 7.0.4 (pre-built) on Tiger due to an old libiconv: ​https://github.com/macports/macports-ports/pull/14674