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
