Updating ffmpeg ...

Tue Oct 30 18:21:10 UTC 2018

On Oct 29, 2018, at 22:03, Michael wrote:

> On 2018-10-29, at 7:47 PM, Ryan Schmidt wrote:
> 
>> On Oct 29, 2018, at 21:26, Michael wrote:
>> 
>>> So two things when I attempted to update macports and ffmpeg.
>>> 
>>> Number 1: There was a HUGE chain of things to update first. Surprising to me was what looked like all of Xwindows.
>>> 
>>> XWindows? Why?
>>> 
>>> After X, it updated openssl, then sqlite3, then python select, then python, then more of X ... followed ultimately by graphite2.
>>> 
>>> But when all was done, ffmpeg fails. Again.
>>> 
>>> So, I went to the trac page, to try to find that bug report for ffmpeg that I saw in the past, that I thought I did a "me too" CC on.
>>> 
>>> ...
>>> 
>>> I could not find it. Anywhere. This is the new trac bug system, as far as I can tell.
>>> 
>>> Ffmpeg's success rate for about 2 years has been zero. I will get some variation on:
>>> 
>>> bash-3.2# port activate ffmpeg @4.0.1_0+gpl2
>>> --->  Computing dependencies for ffmpeg
>>> --->  Deactivating ffmpeg @3.1.4_0+gpl2
>>> --->  Cleaning ffmpeg
>>> --->  Activating ffmpeg @4.0.1_0+gpl2
>>> --->  Cleaning ffmpeg
>>> --->  Some of the ports you installed have notes:
>>> ffmpeg has the following notes:
>>>  *******
>>>  ******* This build of ffmpeg includes GPLed code and
>>>  ******* is therefore licensed under GPL v2 or later.
>>>  *******
>>>  ******* The following modules are GPLed:
>>>  *******
>>>  *******      postproc
>>>  *******      libx264
>>>  *******      libx265
>>>  *******      libxvid
>>>  *******
>>>  ******* To include all nonfree, GPLed and LGPL code use variant +nonfree.
>>>  ******* To remove nonfree and GPLed code leaving only LGPL code remove the
>>>  ******* +gpl2 variant.
>>>  *******
>>> bash-3.2# ffmpeg
>>> dyld: Library not loaded: /opt/local/lib/libx264.152.dylib
>>> Referenced from: /opt/local/bin/ffmpeg
>>> Reason: image not found
>>> Trace/BPT trap: 5
>>> bash-3.2# 
>>> 
>>> I was attempting to restore older versions to try to find the old one that used to work, but none of them did.
>>> 
>>> And I know I've reported this issue before.
>> 
>> Sorry to hear you're having problems with ffmpeg. I don't think others are experiencing problems.
>> 
>> You should not see "dyld: Library not loaded: /opt/local/lib/libx264.152.dylib" since that library is provided by the x264 port, on which ffmpeg does declare a dependency. If you are seeing that error, make sure that x264 is updated to the latest version, currently 20171225. You can check using "port installed x264".
> 
> To clarify: I was attempting to go back to older versions that "just worked". But installing older versions no longer makes them work.

If you are in the habit of using that solution, that could explain how you got into this situation. Yes MacPorts does have the capability of reactivating older versions of a port, but when the old and new versions contain or use different library versions, that can cause these types of problems.

> Fwiw:
> 
> bash-3.2# port installed ffmpeg
> The following ports are currently installed:
>  ffmpeg @3.0.2_0+gpl2
>  ffmpeg @3.1.1_0+gpl2
>  ffmpeg @3.1.3_0+gpl2
>  ffmpeg @3.1.4_0+gpl2
>  ffmpeg @3.2_0+gpl2
>  ffmpeg @3.2.2_1+gpl2
>  ffmpeg @3.2.2_3+gpl2
>  ffmpeg @3.2.2_4+gpl2
>  ffmpeg @3.2.4_1+gpl2
>  ffmpeg @3.2.4_2+gpl2
>  ffmpeg @3.2.4_3+gpl2
>  ffmpeg @3.2.4_4+gpl2
>  ffmpeg @3.3.2_1+gpl2
>  ffmpeg @3.3.3_0+gpl2
>  ffmpeg @3.3.3_1+gpl2
>  ffmpeg @3.3.4_0+gpl2
>  ffmpeg @4.0_1+gpl2
>  ffmpeg @4.0.1_0+gpl2 (active)
> bash-3.2# port installed x264
> The following ports are currently installed:
>  x264 @20160119_0
>  x264 @20161201_0 (active)
>  x264 @20170522_0
>  x264 @20171225_0
> bash-3.2# 
> 
> In general: While compiling, mac ports will ensure that everything is updated to the newest version, even if deactivating a library port results in removing library version that other older ports might want. But when re-activating older versions, macports will make no attempt to figure out what else needs to be reactivated, and not only is there no way to recover a previously working set of activations, there's no way to deal with "program X wants older library x, while program Y wants newer library y."
> 
> They might be in different files, but since they are installed by different versions of the same port, they won't live at the same time.
> 
> Macports has the dependency diamond problem in spades.

I am not familiar with the term "dependency diamond problem" but you are correct that when you activate one port, MacPorts makes no attempt to figure out what other ports might need to be activated -- with the exception that if a port depends on another port that is deactivated, it will activate the latest version of that port. But if you have the latest version of the dependency installed and deactivated, and an older version of the dependency installed and activated, MacPorts will assume you did that deliberately and will leave that alone.

We treat MacPorts as a whole collection, so we expect that when there are outdated ports, you will upgrade all of them together. This is why we recommend and document running "sudo port upgrade outdated", and not upgrading individual ports. You *can* upgrade individual ports if you know what you're doing, but it can result in things breaking due to library version mismatches or other reasons. The rev-upgrade feature was introduced to detect and fix library version breakages automatically, but if you have it turned off in macports.conf then you won't benefit from it.

It is normal for there to be only a single version of a library offered in MacPorts. In some special cases, we offer multiple ports for a single software package, for example when a developer has introduced a new "version 2" of a library that breaks compatibility with the older one. We then offer a version 1 port and a version 2 port so that old software can use version 1 and new software can use version 2. (An example is libsdl and libsdl2.) If the developer has not prepared for this type of packaging, it can take a special effort to offer multiple ports, because the portfile author has to ensure that the two ports install their files to different places and has to ensure that each dependent is aware of where the files it needs are located. So we only want to go to that effort when it's really necessary and worthwhile. With x264 and x265, it's neither, because they change their library versions all the time and we want all software to always use the latest version. And that's what we do.

For example, here's where x265 was updated to version 2.9:

https://github.com/macports/macports-ports/commit/c4726e560c5bba1c7399477e304533c3fba8e563

And here's the next commit, where all the ports that link with x265 (including ffmpeg) had their revisions increased to make them rebuilt with the new library version:

https://github.com/macports/macports-ports/commit/3d924c0fbccea24a7625853e9849add198837f27

This leaves ffmpeg at version 4.0.2 revision 1, which I note is newer than what you have installed.

> As for that x264 issue, trying to fix that gives this next problem:
> 
> bash-3.2# ffmpeg
> dyld: Library not loaded: /opt/local/lib/libx265.160.dylib
>  Referenced from: /opt/local/bin/ffmpeg
>  Reason: image not found
> Trace/BPT trap: 5
> bash-3.2# port contents x265
> Port x265 contains:
>  /opt/local/bin/x265
>  /opt/local/include/x265.h
>  /opt/local/include/x265_config.h
>  /opt/local/lib/libx265.165.dylib
>  /opt/local/lib/libx265.a
>  /opt/local/lib/libx265.dylib
>  /opt/local/lib/pkgconfig/x265.pc
> bash-3.2# port installed x265
> The following ports are currently installed:
>  x265 @2.1_0
>  x265 @2.2_0
>  x265 @2.3_0
>  x265 @2.4_0
>  x265 @2.5_0
>  x265 @2.6_0
>  x265 @2.8_1
>  x265 @2.9_0 (active)
> bash-3.2# 
> 
> As I said, I can't keep multiple version of libx265.xxx around from different versions; no matter what I do, finding a working combo for ffmpeg will break things that don't like that version of libraries.

So you have x265 @2.9 and ffmpeg @4.0.1_0 installed, but ffmpeg @4.0.2_1 is the first version that is meant to be used with x265 @2.9.

I can see another way that you could get into this kind of situation. You might have upgraded x264 and x265, found that this broke something, and fixed it by reactivating an older x264 and x265. Because you also already had the latest versions of those ports installed (but deactivated), when you later upgraded ffmpeg MacPorts would not reactivate the newest versions of x264 and x265. This would result in the latest ffmpeg being built against old library versions of x264 and x265, which is not what we intended.

My recommendation: Look through the output of "port installed actinact" and identify all of the ports where you have reactivated an older version. Activate the latest version of each. You may want to turn off rev-upgrade in macports.conf while you do this cleanup to avoid unnecessary rebuilds. Also "sudo port selfupdate" and "sudo port upgrade outdated". When you're done, turn rev-upgrade back on and run it once manually with "sudo port rev-upgrade" and let it rebuild anything that's broken. You should now have a consistent set of working ports, and using "sudo port selfupdate" and "sudo port upgrade outdated" should keep it consistent in the future if you refrain from reactivating old versions.

>> And yes, the ffmpeg dependency chain does include some X11 ports. ffmpeg has an x11 variant which is not enabled by default, but some of ffmpeg's dependencies have x11 variants that are enabled by default. If you don't want to use X11, often you can ask MacPorts to use Quartz instead. If you want to do that, it's best to uninstall all ports first, then add "+quartz -x11" to variants.conf and reinstall the ports you want.
> 
> Which is odd, because I do have those options on most things I've installed.
> 
> The real problem: How in the bleep do I even determine where in the dependency chain the X11 dependency is declared? As I wrote that previous line (I've got +quartz on a lot of things), it occurred to me that there might be a mixed quartz/X11 on some of my ports that is confusing the build system.

We don't support mixing and matching x11 and quartz variants, which is why I mentioned that if you want to switch from x11 to quartz or vice versa, you should make the change as a whole for your entire MacPorts prefix in variants.conf and then uninstall and reinstall ports so that they all match that choice.

There are some ports that are excluded from that rule. pango and cairo by default install with both variants at the same time, and that's fine whether you want to use x11 or quartz on other ports. The rule is for the majority of other ports which can only use either x11 or quartz, not both. If the goal is to avoid X11 dependencies entirely, pango and cairo can be installed with the quartz variant only.

There are some ports that do not support quartz. You may be able to use these by using their x11 variant if they don't depend on other ports that have x11 variants, but if they do then you may not be able to use these if you switch your installation from x11 to quartz.

You can look at the dependency chain using "port rdeps ffmpeg".