Conan-center-index: [package] libalsa/1.1.9: ALSA_CONFIG_DIR and the like are wrong

[Chnossos]

Package and Environment Details

• Package Name/Version: libalsa/1.1.9
• Operating System+version: Linux Fedora 32
• Compiler+version: GCC 10
• Conan version: conan 1.28.0
• Python version: Python 3.8.5

Conan profile

[settings]
os=Linux
os_build=Linux
arch=x86_64
arch_build=x86_64
compiler=gcc
compiler.version=10
compiler.libcxx=libstdc++11
build_type=Release
[options]
[build_requires]
[env]

Steps to reproduce

It all started from an issue in the portaudio package from bincrafters.

TL;DR: ALSA_CONFIG_DIR and ALSA_PLUGIN_DIR point to the conan package instead of the system (respectively /usr/share/alsa and /usr/lib64/alsa-lib on my system), resulting in this kind of logs

ALSA lib conf.c:3956:(snd_config_update_r) Cannot access file /home/<user>/.conan/data/libalsa/1.1.9/_/_/package/51e96d1346424f5ef647616231906873cd225eb3/share/alsa/alsa.conf
ALSA lib control.c:1375:(snd_ctl_open_noupdate) Invalid CTL hw:0
ALSA lib conf.c:3956:(snd_config_update_r) Cannot access file /home/<user>/.conan/data/libalsa/1.1.9/_/_/package/51e96d1346424f5ef647616231906873cd225eb3/share/alsa/alsa.conf
ALSA lib control.c:1375:(snd_ctl_open_noupdate) Invalid CTL hw:1
ALSA lib conf.c:3956:(snd_config_update_r) Cannot access file /home/<user>/.conan/data/libalsa/1.1.9/_/_/package/51e96d1346424f5ef647616231906873cd225eb3/share/alsa/alsa.conf
ALSA lib control.c:1375:(snd_ctl_open_noupdate) Invalid CTL hw:2
test: sources/src/hostapi/alsa/pa_linux_alsa.c:1453: BuildDeviceList: Assertion `devIdx < numDeviceNames' failed.
fish: “./build/bin/test” terminated by signal SIGABRT (Abort)

Export ALSA_CONFIG_DIR to /usr/share/alsa fixes the termination but now plugins can't be loaded:

ALSA lib pcm_direct.c:2023:(snd1_pcm_direct_parse_open_conf) Unknown field tstamp_type
ALSA lib pcm_direct.c:2023:(snd1_pcm_direct_parse_open_conf) Unknown field tstamp_type
ALSA lib pcm.c:2564:(snd_pcm_open_noupdate) Unknown PCM cards.pcm.rear
ALSA lib pcm.c:2564:(snd_pcm_open_noupdate) Unknown PCM cards.pcm.center_lfe
ALSA lib pcm.c:2564:(snd_pcm_open_noupdate) Unknown PCM cards.pcm.side
ALSA lib pcm_route.c:869:(find_matching_chmap) Found no matching channel map
ALSA lib pcm_route.c:869:(find_matching_chmap) Found no matching channel map
ALSA lib pcm_route.c:869:(find_matching_chmap) Found no matching channel map
ALSA lib pcm_route.c:869:(find_matching_chmap) Found no matching channel map
ALSA lib dlmisc.c:285:(snd1_dlobj_cache_get) Cannot open shared library /home/<user>/.conan/data/libalsa/1.1.9/_/_/package/51e96d1346424f5ef647616231906873cd225eb3/lib/alsa-lib/libasound_module_pcm_pulse.so ((null): /home/pierre/.conan/data/libalsa/1.1.9/_/_/package/51e96d1346424f5ef647616231906873cd225eb3/lib/alsa-lib/libasound_module_pcm_pulse.so: cannot open shared object file: No such file or directory)
ALSA lib dlmisc.c:285:(snd1_dlobj_cache_get) Cannot open shared library /home/<user>/.conan/data/libalsa/1.1.9/_/_/package/51e96d1346424f5ef647616231906873cd225eb3/lib/alsa-lib/libasound_module_pcm_pulse.so ((null): /home/<user>/.conan/data/libalsa/1.1.9/_/_/package/51e96d1346424f5ef647616231906873cd225eb3/lib/alsa-lib/libasound_module_pcm_pulse.so: cannot open shared object file: No such file or directory)
ALSA lib pcm_direct.c:2023:(snd1_pcm_direct_parse_open_conf) Unknown field tstamp_type
ALSA lib dlmisc.c:285:(snd1_dlobj_cache_get) Cannot open shared library /home/<user>/.conan/data/libalsa/1.1.9/_/_/package/51e96d1346424f5ef647616231906873cd225eb3/lib/alsa-lib/libasound_module_pcm_pulse.so ((null): /home/<user>/.conan/data/libalsa/1.1.9/_/_/package/51e96d1346424f5ef647616231906873cd225eb3/lib/alsa-lib/libasound_module_pcm_pulse.so: cannot open shared object file: No such file or directory)
ALSA lib dlmisc.c:285:(snd1_dlobj_cache_get) Cannot open shared library /home/<user>/.conan/data/libalsa/1.1.9/_/_/package/51e96d1346424f5ef647616231906873cd225eb3/lib/alsa-lib/libasound_module_pcm_pulse.so ((null): /home/<user>/.conan/data/libalsa/1.1.9/_/_/package/51e96d1346424f5ef647616231906873cd225eb3/lib/alsa-lib/libasound_module_pcm_pulse.so: cannot open shared object file: No such file or directory)
Cannot connect to server socket err = No such file or directory
Cannot connect to server request channel
jack server is not running or cannot be started
JackShmReadWritePtr::~JackShmReadWritePtr - Init not done for -1, skipping unlock
JackShmReadWritePtr::~JackShmReadWritePtr - Init not done for -1, skipping unlock

Exporting ALSA_PLUGIN_DIR unfortunately doesn't change anything.

[XxAlpha25xX]

Exactly the same for me, have you find any solution ?

[GreenDjango]

You can use this temporary fix:
export ALSA_CONFIG_DIR=/usr/share/alsa for config dir
ln -s /usr/lib64/alsa-lib/ ~/.conan/data/libalsa/<VERSION>/_/_/package/<HASH>/lib/ for plugin dir
ln -s /usr/lib64/pkgconfig/ ~/.conan/data/libalsa/<VERSION>/_/_/package/<HASH>/lib/ for pkg dir

[XxAlpha25xX]

Thanks a lot :)

[Forbinn]

This solution only works if you actually build the package on your system. But if you just install it from conan-center repository then the path become /tmp/c3ipr/pr_1676_3_0_7/.conan/data/libalsa/1.1.9/_/_/package/d48130e0dd76369b1338deb3b2372c5a649f9f2d/lib/alsa-lib/.

This is due to the fact that the plugin path is set at compile time and because the package is pre-build on another machine then the path is incorrect.

A solution would be to add the compilation of alsa-plugins in the libalsa package and force a relative path for the plugin path in the compilation of libalsa.

What do you think of this solution?

[GreenDjango]

Change path via conanfile.py before compilation (with --with-configdir=dir, --with-plugindir=dir, --with-pkgconfdir=dir for alsa configure.ac), give me errors because it try to remove and replace my principal installation of alsa

[Forbinn]

Yes, you cannot precise the configdir location or it will try to replace your current configuration with the one inside the alsa sources.

But what we can do for now is just precise the --with-plugindir=/usr/lib64/alsa-lib for 64 bits systems and --with-plugindir=/usr/lib/alsa-lib for 32 bits systems. With this new configuration alsa will load the system plugins and we can precise the configuration directory location via the environment variable ALSA_CONFIG_DIR.

This makes the package usable at the price of having the correct alsa plugins already installed on your system and the use of an environment variable.

Do you think it is a viable solution?

[ericriff]

Yes, you cannot precise the configdir location or it will try to replace your current configuration with the one inside the alsa sources.

But what we can do for now is just precise the --with-plugindir=/usr/lib64/alsa-lib for 64 bits systems and --with-plugindir=/usr/lib/alsa-lib for 32 bits systems. With this new configuration alsa will load the system plugins and we can precise the configuration directory location via the environment variable ALSA_CONFIG_DIR.

This makes the package usable at the price of having the correct alsa plugins already installed on your system and the use of an environment variable.

Do you think it is a viable solution?

Is ALSA_CONFIG_DIR checked at buildtime or runtime? I just came across the same issue.

[Forbinn]

The ALSA_CONFIG_DIR is checked at runtime. For the build time you can precise its default value using --with-configdir option of the ./configure script.

[ericriff]

I don't see setting an env variable each time I want to run my app as a viable solution. Setting the config path at build time is also not good because you loose the ability to move the package. :thinking:

[Forbinn]

Yes, I agree with you but I cannot find another solution.