cmus @2.9.1+aac: configure failed: checking for header <mp4v2/mp4v2.h>... no

[ryandesign (Ryan Carsten Schmidt)]

When cmus is configured with the +aac variant enabled (which it is by default) configuration fails:

checking for LIBSYSTEMD_LIBS (pkg-config)... no
*** Package libsystemd was not found in the pkg-config search path.
*** Perhaps you should add the directory containing `libsystemd.pc'
*** to the PKG_CONFIG_PATH environment variable
*** No package 'libsystemd' found
checking for LIBSYSTEMD_LIBS (pkg-config)... no
*** Package libelogind was not found in the pkg-config search path.
*** Perhaps you should add the directory containing `libelogind.pc'
*** to the PKG_CONFIG_PATH environment variable
*** No package 'libelogind' found
checking for WAVPACK_LIBS (pkg-config)... -L/opt/local/lib -lwavpack
checking for WAVPACK_CFLAGS (pkg-config)...
checking for header <mp4v2/mp4v2.h>... no
checking for header <mp4.h>... no
configure failed.

I assume that the remarks about libsystemd are irrelevant since macOS systems don't use systemd, they use launchd.

I assume the relevant message is about mp4v2. cmus does depend on the mp4v2 port, which does provide the mp4v2/mp4v2.h header. I don't know why the configuration process fails to find it. This port uses an unusual hand-baked non-autoconf configure script so it is more difficult to figure out because it does not appear to leave behind a config.log to document its actions.

[ryandesign (Ryan Carsten Schmidt)]

checking for header <mp4v2/mp4v2.h>... no

This is because after cmus was updated to 2.1.9, mp4v2 was ​updated to version 4.1.6 of the TechSmith fork. The problem remains if I upgrade mp4v2 to 5.0.1. If I backdate mp4v2 to the original 2.0.0, cmus 2.9.1 builds fine. It also builds fine if I use version 4.1.3 of the TechSmith fork, but not 4.1.4 or later.

TechSmith introduced a backward-incompatible change in their mp4v2 4.1.4. Specifically, they added a second argument to the MP4Read function, and defined that second argument to have a default value of nullptr, which is a C++ keyword, even though this is supposed to be a C library. This of course breaks other programs that try to use libmp4v2 from C code, like cmus.

The cmus configure script checks for the presence of headers by doing a trial compilation including that header. If we try that manually, we see the problem:

$ echo '#include <mp4v2/mp4v2.h>' | cc -I/opt/local/include -c -x c -
In file included from <stdin>:1:
In file included from /opt/local/include/mp4v2/mp4v2.h:58:
/opt/local/include/mp4v2/file.h:336:34: error: use of undeclared identifier 'nullptr'
    ShouldParseAtomCallback cb = nullptr );
                                 ^
1 error generated.

I filed a cmus issue: ​mp4v2 not found if using TechSmith mp4v2 4.1.4 or later.

There also existed a related cmus issue: ​Segmentation fault when opening any m4a/m4b/mp4 file.

An issue has also been filed with TechSmith: ​Version 4.1.4/4.1.5 breaks applications written in C (such as cmus). The developers have not responded. This is troubling. It suggests they don't care about maintaining backward compatibility and calls into question whether we should be using this fork in MacPorts. If we do want to continue using it, we have to audit and fix all the other ports that use mp4v2 too.

[ryandesign (Ryan Carsten Schmidt)]

Replying to ryandesign:

which is a C++ keyword, even though this is supposed to be a C library.

Or rather, the library is written in C++, however it is documented (in doc/MP4.3) that the library is intended to be callable from C or C++ and that it uses C calling conventions, which TechSmith has now broken.

[mkuron (Michael Kuron)]

That is bad. At the time I updated the port, I only checked a few dependents, not expecting them to do something like this. Could we add a patch to MacPorts that reverts the introduction of this C++-ism? Going back to the umaintained Google Code repo is probably not a good idea as it‘s truly ancient, and I vaguely recall that it had a few security vulnerabilities that Techsmith fixed over the years.

[mrkapqa]

am having also issue with cmus and high sierra. adding the logfile if someone can something do about it. thank you

[mrkapqa]

i dont know why it says target 10.12 but my system is actually running high sierra.

[kencu (Ken)]

Well, I guess this is another one of my bonehead moves.

Updating mp4v2 to the newer version seemed to make sense at the time I committed the PR, but clearly was a very silly thing to do. Nobody else on Earth seems to use that version, and software like cmus is not written to support it.

Should we just revert ourselves back to mp4v2 v2.0.0 like we had been at for many years, and then things will be back to the way they were?

For right now, cmus builds fine if you delete the +aac variant, for anyone tremendously frustrated.

Apologies.

[kencu (Ken)]

or this ​https://github.com/macports/macports-ports/pull/11781/commits/df513ae89e941831b2183633b70accdc50330644

[ryandesign (Ryan Carsten Schmidt)]

Replying to mrkapqa:

i dont know why it says target 10.12 but my system is actually running high sierra.

The log shows two installation attempts: one on August 4 on 10.12 and the second on August 7 on 10.13.

[ryandesign (Ryan Carsten Schmidt)]

Replying to kencu:

Updating mp4v2 to the newer version seemed to make sense at the time I committed the PR, but clearly was a very silly thing to do.

Not at all; updating seems reasonable to me too, and I appreciate the effort to keep ports updated. I don't think we could have anticipated that it would cause this problem.

Nobody else on Earth seems to use that version, and software like cmus is not written to support it.

There are some other distributions using it, I think (see ​https://repology.org/project/libmp4v2/versions), which may lead to other software adopting its new features.

Should we just revert ourselves back to mp4v2 v2.0.0 like we had been at for many years, and then things will be back to the way they were?

That would fix cmus... but the patch from sandreas that was added to the port will be needed to be able to add a port for m4b-tool (also by sandreas) which I was interested in doing. Perhaps the patch from sandreas can be backported to version 2.0.0. Or we could try downgrading to 4.1.3, right before the incompatibility was introduced—presuming that no other incompatibilities exist.

[mkuron (Michael Kuron)]

Perhaps the patch from sandreas can be backported to version 2.0.0.

mp4v2 had a few security vulnerabilities reported back in 2018 that got CVE numbers assigned and were fixed by TechSmith. So those would need to be backported as well. In the end, we would probably end up with something that would be quite similar to TechSmith's current version.

Or we could try downgrading to 4.1.3

We shouldn't downgrade below 4.1.6 because that fixes some issues (​https://github.com/TechSmith/mp4v2/commit/8d6307ea1e70c0a44dd2a64c4fa1a8f42b803ebf) that had already been fixed earlier in the sandreas fork.

[ryandesign (Ryan Carsten Schmidt)]

In 799e13d755088c872e7cb46b2aff978a907d5260/macports-ports (master):

mp4v2: Revert to 4.1.3

Revert to version 4.1.3 plus patches to fix issues that were fixed in
later versions.

4.1.4 changed the signature of the MP4Read function to have a second
argument and used a C++ default value feature in doing so, thus breaking
all the ports that want to use this library from C code. Those other
ports either fail to build or fail to detect that mp4v2 is installed and
build themselves without mp4v2 support.

Closes: #63297

A solution to fix the API breakage was proposed to MacPorts but we
should not attempt to declare ourselves the owners of this software. We
should not introduce yet another different version of this software that
is unlike what other distros ship. The fix should be proposed to the
developers of this software and they can decide (or not) what to do. In
anticipation of the developers not responding to such a proposal, like
they have already failed for one year to respond to the bug report about
the breakage, let us stay on the last unbroken version and backport any
needed bugfixes until such a time as the current developers begin
addressing bug reports or a better-maintained fork emerges.

Closes: ​https://github.com/macports/macports-ports/pull/11781

Before, with mp4v2 @5.0.1_0:

cmus @2.9.1_0+aac:
checking for header <mp4v2/mp4v2.h>... no
checking for header <mp4.h>... no
configure failed.

ices0 @0.4_3:
In file included from in_mp4.c:32:
In file included from /opt/local/include/mp4v2/mp4v2.h:58:
/opt/local/include/mp4v2/file.h:336:34: error: use of undeclared identifier 'nullptr'

libextractor @1.4_3:
checking mp4v2/mp4v2.h usability... no
checking mp4v2/mp4v2.h presence... yes
configure: WARNING: mp4v2/mp4v2.h: present but cannot be compiled
configure: WARNING: mp4v2/mp4v2.h: check for missing prerequisite headers?
configure: WARNING: mp4v2/mp4v2.h: see the Autoconf documentation
configure: WARNING: mp4v2/mp4v2.h: section "Present But Cannot Be Compiled"
configure: WARNING: mp4v2/mp4v2.h: proceeding with the compiler's result
configure: WARNING: ## --------------------------------------- ##
configure: WARNING: ## Report this to bug-libextractor@… ##
configure: WARNING: ## --------------------------------------- ##
checking for mp4v2/mp4v2.h... no

After, with mp4v2 @4.1.3_0:

cmus @2.9.1_0+aac:
checking for header <mp4v2/mp4v2.h>... yes
checking for header <neaacdec.h>... yes
checking for MP4_LIBS (-lmp4v2 -lfaad -lm)... yes

ices0 @0.4_4:
successful build

libextractor @1.4_3:
checking mp4v2/mp4v2.h usability... yes
checking mp4v2/mp4v2.h presence... yes
checking for mp4v2/mp4v2.h... yes