libao.so contains hardcoded paths

[Daniel A. Freer]

libao2 currently hard codes the paths to it's plugins, located in /usr/lib/ao/plugins-2/.

This can be shown by running this command:
[code]strings /usr/lib/libao.so.2 | grep / [/code]

This becomes a problem when the 32-bit version of libao is used on a 64-bit system. It'll check /usr/lib/ao/plugins-2/ instead of /usr/lib32/ao/plugins-2/, which causes a segfault in zsnes (a 32-bit only binary).

This can temporarily be fixed on user's systems by symbolically linking the 32-bit plugins located in /usr/lib32/ao/plugins-2/ to /usr/lib/ao/plugins-2/. A better fix would be to use a relative path such as ./ao/plugins-2/ instead of the absolute path of /usr/lib/ao/plugins-2/.

This affects ia32-libs in hardy especially, since it now contains libao2.

[Daniel T Chen (crimsun)]

There is a dependency chain: ia32-libs simply needs to be regenerated after libao is fixed.

[Gilles Casse (gcasse)]

AO_PLUGIN_PATH depends on $libdir supplied by configure.
It would be possible (but perhaps not desirable?) to build a specific version without modifying the upstream source.
Changes in the debian dir. such as e.g. in debian/rules:
-confflags = --prefix=/usr --enable-static
+confflags = --prefix=/usr --libdir=/usr/lib32 --enable-static

[Scott Ritchie (scottritchie)]

That's not possible at the moment Gilles, as ia32-libs simply (stupidly) takes the i386 package files rather than rebuilds them. So any build options for 32-bit ia32-libs would also have to be in the real 32-bit package as well (where /usr/lib32 is incorrect).

[Steve Langasek (vorlon)]

This is resolved for precise, in which libao now uses an architecture-specific ("multiarch") path for its modules.