[pulseaudio-discuss] amd64, pulseaudio, and nspluginwrapper

[Loïc Minier]

On Sun, Feb 25, 2007, Alex Malinovich wrote:
> I THINK that what's going on is that the wrapper is trying to call the
> 32-bit sound libraries, and there are no 32-bit compatibility libraries
> for pulse (at least in Debian). Does anyone know if this is the case,
> and if so, how to get around it? Is it possible to build a
> pulseaudioia32 or something similar? This is the last remaining step for
> me in the Perfect Setup. Any ideas?

 That would be quite logical indeed; it would be nice to confirm what is
 missing (I suppose libasound_module_pcm_pulse.so isn't loadable), and
 file bugs against the package which could provide such a support.

 Theoritically, everything should be in ia32-libs or ia32-libs-gtk,
 however there are two different things with alsa:
 - alsa is built as biarch, that is the 32-bits compatibility package is
   built on amd64 (other libs are simply built on i386 and copied
   manually in the amd64 package), in lib32asound2; hence, it would be
   logical to build libasound2-plugins as bi-arch as well, I don't know
   whether it is the case, or why it isn't
 - libasound_module_pcm_pulse.so being a plugin, lib32asound2 needs to
   be patched to lookup for 32-bits compatibility plugins under a
   different location, for example it should attempt to load plugins
   from /usr/lib32/alsa-lib _first_, then fallback to /usr/lib/alsa-lib;
   unless it does so already; a strace should confirm this

 But if libasound2-plugins needs a new binary package and/or a bi-arch
 build, it's too late for etch, so you might want to request inclusion
 in ia32-libs in this case.

   HTH,
-- 
Loïc Minier <lool at dooz.org>