Bug 114426 - libasound.so from emul-linux-x86-soundlibs incompatible with alsa-lib-1.0.10
|
Bug#:
114426
|
Product: Gentoo Linux
|
Version: unspecified
|
Platform: AMD64
|
|
OS/Version: Linux
|
Status: RESOLVED
|
Severity: normal
|
Priority: P2
|
|
Resolution: FIXED
|
Assigned To: amd64@gentoo.org
|
Reported By: tom@dbservice.com
|
|
Component: Applications
|
|
|
URL:
|
|
Summary: libasound.so from emul-linux-x86-soundlibs incompatible with alsa-lib-1.0.10
|
|
Keywords:
|
|
Status Whiteboard:
|
|
Opened: 2005-12-04 03:29 0000
|
I installed emul-linux-x86-soundlibs and alsa-lib-1.0.10 and I got strange
errors when I tried to run a 64bit app (mplayer) and a 32bit app (wine) at the
same time. The errors were:
ALSA lib pcm_dmix.c:788:(snd_pcm_dmix_open) unable to create IPC shm instance
mplayer: pcm_params.c:187: snd_pcm_hw_param_get_min: Assertion
`!snd_interval_empty(i)' failed.
After compiling alsa-lib-1.0.10 for 32bit and putting the libraries to the right
directory everything works fine.
to compile alsa-lib for 32bit, just use this:
./configure --prefix=/home/yourname/root LDFLAGS="-L/emul/linux/x86/usr/lib
-m32" CFLAGS="-L/emul/linux/x86/usr/lib -m32"
and copy /home/yourname/root/usr/lib/libasound.so.2.0.0 to /emul/linux/x86/usr/lib
Reproducible: Always
Steps to Reproduce:
I'd *highly* appreciate when we can come up with a even more ideal solution on
this
by removing alsa-libs/alsa-oss 32bit from emul-linux-x86-soudnlibs and instead
making alsa-lib/alsa-oss multilib aware, just like sandbox (and glibc) is
compiled for 32bit and 64bit on AMD64 as well.
So why not doing it there the same way?
herbs? kugelfang? any objections?
(In reply to comment #1)
> by removing alsa-libs/alsa-oss 32bit from emul-linux-x86-soudnlibs and instead
> making alsa-lib/alsa-oss multilib aware, just like sandbox (and glibc) is
> compiled for 32bit and 64bit on AMD64 as well.
If we start doing that for sound libs where do we stop? There's libs from 100
odd packages in our emul-libs currently and we surely can't hack every ebuild to
install 32bit libs alongside our native ones. I'd still much rather see us get
actual multilib support into portage i.e track dependencies of multiple abis) so
we wouldn't need to hack ebuilds. See eradicators blog:
http://ramblings.hudscabin.com/index.php?catsel%5B%5D=25
(In reply to comment #2)
> If we start doing that for sound libs where do we stop? There's libs from 100
> odd packages in our emul-libs currently and we surely can't hack every ebuild to
> install 32bit libs alongside our native ones. I'd still much rather see us get
> actual multilib support into portage i.e track dependencies of multiple abis) so
> we wouldn't need to hack ebuilds.
How far away from the real multilib support are we?
And if you say 'so we wouldn't need to hack ebuilds', does that mean the
glibc/gcc ebuilds are hacked?
gcc/glibc are special cases since their build system are multilib aware.
Fixed with soundlibs-2.3.
