Opened 3 years ago
Closed 3 years ago
#63297 closed defect (fixed)
cmus @2.9.1+aac: configure failed: checking for header <mp4v2/mp4v2.h>... no
Reported by: | ryandesign (Ryan Carsten Schmidt) | Owned by: | g5pw (Aljaž Srebrnič) |
---|---|---|---|
Priority: | Normal | Milestone: | |
Component: | ports | Version: | 2.7.99 |
Keywords: | Cc: | Traace, mkuron (Michael Kuron), i0ntempest | |
Port: | cmus, mp4v2 |
Description
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.
Attachments (2)
Change History (14)
Changed 3 years ago by ryandesign (Ryan Carsten Schmidt)
comment:1 follow-up: 2 Changed 3 years ago by ryandesign (Ryan Carsten Schmidt)
Cc: | mkuron added |
---|---|
Port: | mp4v2 added |
comment:2 Changed 3 years ago by 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.
comment:3 Changed 3 years ago by 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.
comment:4 Changed 3 years ago by mrkapqa
am having also issue with cmus and high sierra. adding the logfile if someone can something do about it. thank you
Changed 3 years ago by mrkapqa
comment:5 follow-up: 8 Changed 3 years ago by mrkapqa
i dont know why it says target 10.12 but my system is actually running high sierra.
comment:6 follow-up: 9 Changed 3 years ago by 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.
comment:7 Changed 3 years ago by kencu (Ken)
comment:8 Changed 3 years ago by 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.
comment:9 Changed 3 years ago by 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.
comment:10 Changed 3 years ago by 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.
comment:11 Changed 3 years ago by i0ntempest
Cc: | i0ntempest added |
---|
comment:12 Changed 3 years ago by ryandesign (Ryan Carsten Schmidt)
Resolution: | → fixed |
---|---|
Status: | assigned → closed |
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 ofnullptr
, 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:
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.