[pulseaudio-discuss] asoundrc, configure one virtual device for both input and output

[Tanu Kaskinen]

On Sun, 2012-07-01 at 14:59 +0200, Rafał Mużyło wrote:
> > Does anyone know if the build system of alsa-plugins could be improved
> > so that it doesn't use any external .la files when linking?
> 
> You're asking the wrong question here.
> The build system works exactly like intended.
> It's the problem of la files that's bitten you. It's an annoying legacy
> quirk of libtool.
> If you i.e. pass '-lpulse' via libtool, the la file has priority over
> plain library.
> On modern systems, it's more of a bother than help, so most binary distros
> at this time remove la files even in their -devel packages.
> (though there are packages that actually use their la files, i.e.
> ImageMagick or mpg123, there aren't many of those - mostly just the ones
> using libltdl (and not even all of those))
> See some of the posts on http://blog.flameeyes.eu/tag/libtool on this
> subject.
> 
> Basically, your problem was that you've most likely done "make install"
> for pulseaudio and failed to remove installed la files. That in turn
> added reference to libsamplerate.

You're right: I have never removed the .la files. Now I'm just wondering
why the .la file doesn't anymore appear to have priority over the plain
library. Pulseaudio's .la files are certainly still installed.

> On an related note: "sudo make install" can be a very good advice on
> "how to break your system".

I guess that depends on what you're installing... At least pulseaudio
has been trouble-free for me, because the client library has always
remained backwards compatible, so existing applications keep working (on
version number bumps things tend to stop working, but one "sudo
ldconfig" invocation fixes that).

When I have had trouble with other software that I've installed with
"sudo make install", cleaning it out has been easy, since it's all
nicely separated under /usr/local. The real trouble starts when people
set the install prefix to /usr, overwriting the system files.

If you have better advice for testing self-modified alsa-plugins, I'm
all ears. I know it's possible to install to some random place, or even
avoid installing altogether and running from the source tree. But "make
&& sudo make install" is much simpler, and the worst case is that you
break alsa applications, which you should be able to fix by running
"sudo make uninstall".

... Now I actually tested what "sudo make install" does with
alsa-plugins. Against my assumptions, it didn't install its stuff
under /usr/local. Instead, the plugins were installed
in /usr/lib/alsa-lib, so I guess on most systems the default behavior is
to overwrite the system files... (On Debian it's not so, though, because
the system files are in /usr/lib/x86_64-linux-gnu/alsa-lib.)

I'm not sure if I should declare alsa-plugins broken, because it by
default overwrites the system files. Maybe plugins are a bit special in
this regard: the search path for plugins is not handled the same way as
for "normal" shared libraries. Instead, the plugin search path seems to
be hard-coded into alsa-lib (configurable only at build time), so in
order to test self-built alsa-plugins, you need to make sure that
alsa-lib and alsa-plugins have the same plugindir configured. Therefore,
in order to make "sudo make install" Just Work by default (on non-Debian
systems...), the alsa folks have decided that it's best to overwrite the
system files.

So yes, I probably should have told Amar to compile also alsa-lib from
source, and configure alsa-lib and alsa-plugins with
--with-plugindir=/usr/local/lib/alsa-lib or something like that. With
the advice that I gave, he will probably overwrite the system files, and
I can only hope that it won't cause too much trouble...

-- 
Tanu