Build failure: undeclared variables about bluez-alsa

[borine]

Possibly you need to make distclean in the bluez-alsa directory before running autoreconf -fi. You don't say which was the commit of the last build that worked, nor what commit the above error log is from, so it is impossible for anyone to say with certainty which change caused this for you (builds fine for me).

[arkq]

After one of the recent updates I cannot build new versions any more, getting this error (after some portion of normal compilation output):

If you've pulled new changes to your local git clone, and you've just typed make in already configured build directory, this might happened. Please, clean the build directory before build and also make sure that the git status shows no changes to any file. The simplest approach is to start from scratch (fresh git clone, configure and build).

[Galicarnax]

Sure, this is the first thing I tried, using a clean directory. In fact, just now I tried to build manually (no PKGBUILD) - same error. This is the sequence of my actions:

rm -rf ~/tmp
mkdir ~/tmp
cd ~/tmp
git clone https://github.com/arkq/bluez-alsa.git
cd bluez-alsa
autoreconf --install --force
mkdir build
cd build
../configure --enable-cli --enable-aac --enable-systemd
make

... and I get exactly the same error with undeclared symbols.

nor what commit the above error log is from

It's from the latest commit, as I just did git clone.

You don't say which was the commit of the last build that worked

Unfortunately, I can't say that now, as I update packages on that host about once in 2-4 weeks. What I can say for sure is that there was no problem 2 months ago, and there was this same error already 2 weeks ago. If this is the only option to find the issue, I may try to pinpoint the latest working commit when I have time.

There is some warning from autoreconf, but I don't think it is related:

aclocal: warning: couldn't open directory 'm4': No such file or directory
...

[Galicarnax]

I suspect this is specific to Arch Linux ARM. I have tried to build on regular Arch Linux host (where I never used bluez-alsa), the build completed normally.

[Galicarnax]

So I have tried to build some random commit from March, the same error. Yet, this issue began about 3-4 weeks ago, it definitely built normally in March. So I guess something happened with some other package(s) in one of the recent updates in Arch Linux ARM. Sorry, you can probably close the issue (still, if you have any hints on where to look for the cause of the issue, I would appreciate that).

[borine]

My first suspicion is that gdbus-codegen is missing or very out of date. On Debian that is in package libglib2.0-dev-bin, so probably is in libglib2.0 on Arch (I don't have Arch to check that)

[Galicarnax]

glib2 version 2.80.2-2 is installed, and it provides /usr/lib/libglib-2.0.so. Search for other packages that may contain dbus codegen in official repo of Arch Linux yields no result.

[borine]

bluealsa-iface.c: In function ‘org_bluealsa_pcm1_skeleton_new’:
bluealsa-iface.c:43:28: error: ‘org_bluealsa_pcm1_interface’ undeclared (first use in this function); did you mean ‘org_bluealsa_pcm1_skeleton_new’?
43 | (GDBusInterfaceInfo *)&org_bluealsa_pcm1_interface,
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~
| org_bluealsa_pcm1_skeleton_new

This file has the wrong contents. src/bluealsa-iface.c is a generated file, and it should include the declaration of org_bluealsa_pcm1_interface. So either something is wrong with gdbus-codegen on your system, or else make is finding some old version of this file instead of generating it from the xml within the bluez-alsa source. It might be easier to track down what is happening if you build in a subdirectory so we can more easily use git see what is changing in the source tree.

[Galicarnax]

Problem solved, thank you.

Digging in the direction you provided, I learned about gdbus-codegen, and tried to manually generate the C file from the
XML file:

gdbus-codegen --generate-c-code=bluealsa-iface bluealsa-iface.xml

This gave error:

Traceback (most recent call last):
  File "/usr/bin/gdbus-codegen", line 53, in <module>
    from codegen import codegen_main
  File "/usr/share/glib-2.0/codegen/codegen_main.py", line 30, in <module>
    from . import dbustypes
  File "/usr/share/glib-2.0/codegen/dbustypes.py", line 22, in <module>
    from . import utils
  File "/usr/share/glib-2.0/codegen/utils.py", line 22, in <module>
    import packaging.version
ModuleNotFoundError: No module named 'packaging'

So I installed python-packaging, and - that's it.

Why this error doesn't spring out in the normal build process, and instead some incorrect C file is generated, is a mystery.