[MacPorts] #64212: ffmpeg @4.4.1_1+gpl2: ERROR: zvbi-0.2 not found using pkg-config

MacPorts noreply at macports.org
Tue Dec 28 19:03:07 UTC 2021


#64212: ffmpeg @4.4.1_1+gpl2: ERROR: zvbi-0.2 not found using pkg-config
-------------------------+---------------------
  Reporter:  evanmiller  |      Owner:  mascguy
      Type:  defect      |     Status:  closed
  Priority:  Normal      |  Milestone:
 Component:  ports       |    Version:  2.7.1
Resolution:  fixed       |   Keywords:
      Port:  ffmpeg      |
-------------------------+---------------------

Comment (by kencu):

 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.

-- 
Ticket URL: <https://trac.macports.org/ticket/64212#comment:11>
MacPorts <https://www.macports.org/>
Ports system for macOS


More information about the macports-tickets mailing list