I got doom3 to use alsa on my amd64 system... I unpacked the alsa-lib-1.0.8rc1 package, then configured and built it with -m32 built resulting in 32bit libraries. I copied libasound.so.2.0.0 to /emul/linux/x86/usr/lib/ and created the proper symlinks... then to make things simple, I symlinked to libasound.so.2 from the doom3 directory (it sets LD_LIBRARY_PATH to there). and viola alsa sound in a 32bit app on a 64bit system... You also have to have "Emulation for 32-bit applications" enabled in the alsa section of your kernel. There should be a new alsa-lib ebuild that supports the multilib flag, If I get around to it, I will attempt one.
Don't use -m32/-m64 in portage. You will most likely break something. Use emul-linux-x86-soundlibs until portage fully supports multilib packages.
And FWIW, the multilib USE flag is being retired on amd64. Its effects are on by default starting with 2005.0.
I never said anything about using -m32/-m64 in portage... It's nice to know that 32/64bit environment is going to be the default it will help clear up many issues such as this. Unfortunately I found the emul-linux-x86-soundlibs after posting this bug, which is full of many prebuilt libs, yuk...
The binary alsa libs came back and bit me! The binary 32bit alsalib is version 1.0.5 which finally broke against the version 1.0.8 in my kernel, and 1.0.9rc2 in my 64bit install. So, I had to do what I had done origionally when I posted this. Proving again, binary=bad. On a side note why is -m32/-m64 so evil?
because you should let portage handle it. Also, can youu give me a test case where the 1.0.5 32bit libs fail with the 1.0.8 drivers? I know there's a bug in the 2.6.11 in-kernel drivers, but it should be fixed in the latest g-d-s-2.6.11-rX
Well, emul-linux-x86-soundlibs has been updated, fixing this for now, but I still don't like the emul-linux-x86 package approach. It is never a long-term fix. But whatever, I'll close this bug as this is not a venue to discuss that.
Closing.
