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.
