autoconf-archive broken (_AX_CHECK_GL_MANUAL_LIBS_GENERIC: argument must not be empty)
Cava is not building from source or from AUR on arch The arror is in bothe one: (Arch, Terminal: tillix DE:gnome) /usr/share/automake-1.17/am/depend2.am: error: am__fastdepCC does not appear in AM_CONDITIONAL /usr/share/automake-1.17/am/depend2.am: The usual way to define 'am__fastdepCC' is to add 'AC_PROG_CC' /usr/share/automake-1.17/am/depend2.am: to 'configure.ac' and run 'aclocal' and 'autoconf' again /usr/share/automake-1.17/am/depend2.am: error: AMDEP does not appear in AM_CONDITIONAL /usr/share/automake-1.17/am/depend2.am: The usual way to define 'AMDEP' is to add one of the compiler tests /usr/share/automake-1.17/am/depend2.am: AC_PROG_CC, AC_PROG_CXX, AC_PROG_OBJC, AC_PROG_OBJCXX, /usr/share/automake-1.17/am/depend2.am: AM_PROG_AS, AM_PROG_GCJ, AM_PROG_UPC /usr/share/automake-1.17/am/depend2.am: to 'configure.ac' and run 'aclocal' and 'autoconf' again
I am having the same issue. Full build logs at https://hastebin.skyra.pw/urupixosuh.less
I am running Pipewire 1.2.6 w/ pipewire-pulse.
I'm getting the same issue here too with many more similar errors (using yay)
the real error here is:
configure.ac:306: error: _AX_CHECK_GL_MANUAL_LIBS_GENERIC: argument must not be empty
the other ones are because aclocal failed but my autogen.sh script still tries to run autoconf which then also fails. (I can look into that later)
whenever one of these things happen in arch it is some new maintainer who has taken over some package and started upgrading it to latest version. In this case autoconf-archive.
there is already a thing for it in your forums:
https://bbs.archlinux.org/viewtopic.php?id=300628
they are suggesting downgrading.
found this in the diff between the two versions:
diff autoconf-archive-2023.02.20/m4/ax_check_gl.m4 autoconf-archive-2024.10.16/m4/ax_check_gl.m4
88c88
< #serial 22
---
> #serial 23
190,191c190
< AS_IF([test "X$ax_check_gl_manual_libs_generic_extra_libs" = "X"],
< [AC_MSG_ERROR([AX_CHECK_GL_MANUAL_LIBS_GENERIC argument must no be empty])])
---
> m4_if($1, [], m4_fatal([$0: argument must not be empty]))
it looks legit, but maybe m4_if can't be used this way. AX_CHECK_GL_MANUAL_LIBS_GENERICis only being called from within this script and has not been changed.
nothing I can do. I will also suggest downgrading autoconf-archive
update: it was a bug in the m4 code in the autoconf-archive. it was spotted by the Gentoo folks some days ago:
https://bugs.gentoo.org/941845
it's been fixed in the autoconf source, but there is no release yet. someone reach out to [email protected] and make him downgrade until fix is out.
another option is to remove the autoconf-archive, it will remove the glsl output support, but if you are not planning to use it then it should be no problem
so i fixed that problem but when i reinstalled arch and uninstalled the autoconf-archive and installed cava with yay after it i started it and i got a blank terminal without the towers tested with kitty and tilix terminal with the default config
that sounds like this issue.
SOLVED!
2021.02.02 version of autoconf-archive worked for me!
How? Well.. it's easy. sudo cp ~/Downloads/<your_autoconf> /var/cache/pacman/pkg/ sudo pacman -U file:///var/cache/pacman/pkg/<your_autoconf>
@karlstav you can close this cause i solved it
glad you found a workaround @enessmr, I will keep this issue open until the autoconf-archive arch package is patched. Some arch user will immediately open a new issue here if I close this.
@eli-schwartz, I hate to drag you into this, but looks like ax_check_gl is broken in the last release. Do you know if there will be a new autoconf-archive release soon? Or do i need to craft some workaround? I don't think downgrading the arch package is a good solution. I can't be the only one in the world using ax_check_gl, or maybe I am...
Downgrading the package is an okay solution, kind of. For example, in Gentoo the new version has not been migrated to stable, and will not be migrated since it regresses other packages.
I do know that the autoconf-archive maintainer wants to push a new release. There's other regressions as well, though. See the discussion at:
https://github.com/autoconf-archive/autoconf-archive/pull/313#issuecomment-2426212552 https://github.com/autoconf-archive/autoconf-archive/pull/313#issuecomment-2466116724
So all I can say is that it will hopefully be fixed "soon". :(
I can't be the only one in the world using
ax_check_gl, or maybe I am...
You definitely are not. However, it's quite possible most other users are any of:
- frequenting distros other than Arch, that either:
- update packages much less frequently, hence autoconf-archive is still on version 2021, such as Debian / Fedora
- routinely practice a separation between new package updates and new package updates that are stable for general use (and run CI on the unstable branch as part of determining when new package updates can graduate to stable), such as Gentoo
- packaged in the official Arch repos, which means that build issues are rarely noted except the next time their package has a new stable release, irrespective of when autoconf-archive is released
- producing
make distchecktarballs that can be uploaded to github releases and used for installing
thanks for the input @eli-schwartz, the gl ouput of this app is rarely used I think. So I will just disable the ax_check_gl if the recent autoconf archive version is detected.
What distro do you personally use? I think that uploading a make distcheck tarball to GitHub Releases is the most straightforward solution... that would mean that users no longer need to run autoreconf by default, and autoconf-archive from the release machine is the one that is used (so you can test that it works while releasing).
Users could still run autoreconf themselves, to refresh the configure script using brand new autoconf-archive versions. They just wouldn't be forced to do so.
I am on ubuntu myself. Problem is these arch folks spamming me down with issues because of bleeding edge updates on some build tool. make distcheck sounds like a good idea.
For Arch users who want a concrete workaround:
- Install
downgrade. - Run
sudo downgrade autoconfand choose 2.71 (latest). - Run
sudo downgrade autoconf-archiveand choose 2021.02.19 (latest).
Optional but recommended: Let downgrade add these two to ignore list, otherwise you need to repeat for every cava update.
Either:
- Run
makepkg -siwith thecava-gitPKGBUILD. - Run
yayorparuto automatically do this.
--> cava builds and runs with the latest git version.