Ideally esound figures out at runtime whether ALSA is being used and
runs the alsa code automagically and falls back to OSS if it doesn't
find ALSA, but this is not so (yet... I have yet to hack it in :-).
For the time being could we have an "esound-alsa" package (which in rpm
parlance provides "esound") and is built without the --disable-alsa
flag? Or how about an esound package with both oss and alsa enabled
binaries and using that "alternatives" switch stuff you guy got now?
I have included a specfile for esound-alsa. I tried to build it on my
system but the esd cores. BUT WAIT! Read on! If I link the esd
completely staticly:
$ ldd esd
not a dynamic executable
it runs fine. If I link even just one thing dynamically (just glibc for
instance):
$ ldd esd
libc.so.6 => /lib/libc.so.6 (0x40020000)
/lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000)
It cores. I am sure this is a problem with my system (or more likely
Cooker's gcc/glibc/hackkernel/alsa combination) however. There is no
reason why this esound-alsa should not work fine completely dynamically
linked.
So this brings up another issue however. Why does something work
staticially linked but blow up dynamically linked? That HAS to be a
problem with the way things are being/have been built. gcc 2.96
perhaps?
b.
--
Brian J. Murrell
