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".
