On 1/10/20 2:20 PM, Douglas R. Reno via blfs-dev wrote:
Hi folks,
Earlier today, I attempted to build alsa-tools on my 32-bit machine.
There's a few utilities in there that are used for patching the
firmware for the HD Audio cards, as well as those which have proper
Sound Blaster emulation built in (this system has a Creative chipset
that communicates through HD Audio. I think this also affects users of
newer Creative Sound Blaster cards as well, including those released
last year since those most definitely use HD Audio).
It seems that in alsa-lib-1.2.1.2, the ALSA developers merged the
Linux 5.4 sound API headers, and it has caused a lot of breakage in
alsa-tools (and potentially other ALSA users as well).
On December 28th, Jean-Marc Pigeon posted to -dev about breakage in
alsa-tools. I used the sed that he provided in that email, and the
build got a bit farther, but then crashed on ld10k1:
In file included from /usr/include/alsa/asoundlib.h:54,
from ld10k1_fnc.c:33:
/usr/include/alsa/pcm.h:281:3: note: previous declaration of
‘snd_pcm_format_t’ was here
281 | } snd_pcm_format_t;
| ^~~~~~~~~~~~~~~~
In file included from /usr/include/alsa/sound/emu10k1.h:27,
from ld10k1_fnc.c:35:
/usr/include/sound/asound.h:273:23: error: conflicting types for
‘snd_pcm_subformat_t’
273 | typedef int __bitwise snd_pcm_subformat_t;
| ^~~~~~~~~~~~~~~~~~~
In file included from /usr/include/alsa/asoundlib.h:54,
from ld10k1_fnc.c:33:
/usr/include/alsa/pcm.h:288:3: note: previous declaration of
‘snd_pcm_subformat_t’ was here
288 | } snd_pcm_subformat_t;
| ^~~~~~~~~~~~~~~~~~~
In file included from /usr/include/alsa/sound/emu10k1.h:27,
from ld10k1_fnc.c:35:
/usr/include/sound/asound.h:304:23: error: conflicting types for
‘snd_pcm_state_t’
304 | typedef int __bitwise snd_pcm_state_t;
| ^~~~~~~~~~~~~~~
In file included from /usr/include/alsa/asoundlib.h:54,
from ld10k1_fnc.c:33:
/usr/include/alsa/pcm.h:313:3: note: previous declaration of
‘snd_pcm_state_t’ was here
313 | } snd_pcm_state_t;
| ^~~~~~~~~~~~~~~
In file included from /usr/include/alsa/sound/emu10k1.h:27,
from ld10k1_fnc.c:35:
/usr/include/sound/asound.h:837:23: error: conflicting types for
‘snd_ctl_elem_type_t’
837 | typedef int __bitwise snd_ctl_elem_type_t;
| ^~~~~~~~~~~~~~~~~~~
In file included from /usr/include/alsa/asoundlib.h:58,
from ld10k1_fnc.c:33:
/usr/include/alsa/control.h:88:3: note: previous declaration of
‘snd_ctl_elem_type_t’ was here
88 | } snd_ctl_elem_type_t;
| ^~~~~~~~~~~~~~~~~~~
In file included from /usr/include/alsa/sound/emu10k1.h:27,
from ld10k1_fnc.c:35:
/usr/include/sound/asound.h:847:23: error: conflicting types for
‘snd_ctl_elem_iface_t’
847 | typedef int __bitwise snd_ctl_elem_iface_t;
| ^~~~~~~~~~~~~~~~~~~~
In file included from /usr/include/alsa/asoundlib.h:58,
from ld10k1_fnc.c:33:
/usr/include/alsa/control.h:107:3: note: previous declaration of
‘snd_ctl_elem_iface_t’ was here
107 | } snd_ctl_elem_iface_t;
| ^~~~~~~~~~~~~~~~~~~~
make[2]: *** [Makefile:572: ld10k1-ld10k1_fnc.o] Error 1
make[2]: Leaving directory '/sources/alsa-tools-1.1.7/ld10k1/src'
make[1]: *** [Makefile:429: all-recursive] Error 1
make[1]: Leaving directory '/sources/alsa-tools-1.1.7/ld10k1'
make: *** [Makefile:304: all] Error 2
There seems to be a lot of conflicting type errors here. For
reference, here is the sed that he posted as well as a link to the
posting:
#to fix problem with __user definition within cxx files
sed -i \
-e "/#include/i #define __user" \
hdspconf/src/*.cxx \
hdspmixer/src/*.cxx \
hdsploader/hdsploader.c
http://lists.linuxfromscratch.org/pipermail/blfs-dev/2019-December/037059.html
I've adapted the sed to include the files in ld10k1/src/*.c as well,
but that has made no difference on this.
Upon looking upstream, I found many changes to alsa-lib since the
1.2.1.2 release, most of them bugfixes. Three of them in particular
stand out:
https://git.alsa-project.org/?p=alsa-lib.git;a=commitdiff;h=ae564665ec261cf104de499b1cdda3564070fc65
https://git.alsa-project.org/?p=alsa-lib.git;a=commit;h=75584fe660880b332fbf60dd7968e2ed8b49a38b
https://git.alsa-project.org/?p=alsa-lib.git;a=commit;h=59792f467b38d6a4c4dffdb30528f7fb03d23d96
The problem with applying these is the amount of changes involved. The
first commit listed above, ae564665, is well over 7,000 lines long,
and adds some complete new headers to a new folder called "uapi" and
installs them. I've attempted to use the standard patch method on
these into an alsa-lib extract, and get many rejections. I can't find
a way on their site to download just the patch and apply it either, as
trying to download it with wget gives me a HTML document instead.
OpenSUSE has a patchset of 31 total patches for this release of
alsa-lib here:
https://build.opensuse.org/package/show/openSUSE:Factory/alsa
My question is: what should we do to fix this? As far as I can see, we
only have a few choices:
- Try applying just the three commits listed above, but potentially
have problems with the libatopology library
- Revert to alsa-lib-1.2.1.1 (untested, may cause problems with
Linux-5.4)
- Determine a fix for alsa-tools instead (but risk problems with other
ALSA-using applications)
- Create a patch containing all 31 from OpenSUSE (time consuming)
I've noticed that ALSA seems to go a while inbetween releases. These
changes were crafted 21 days ago, and there has been no release since
then to fix them. This was originally reported to us on 12/28/2019.
Thank you,
- Doug
I dropped a temporary fix into r22565. This removes the sb16_csp and
ld10k1 utilities for the time being, and patches the hsdp* programs to
work with the newer headers. We need to reexamine this before the 9.1
release or after the next version of alsa-lib is released
--
http://lists.linuxfromscratch.org/listinfo/blfs-dev
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page
