Hear me out first of all: if I'm opening this bug it's because I've confirmed that some of the .la that your package installs are totally bogus: /usr/lib/python2.6/site-packages/gpod/_gpod.la These files are installed as either part of Ruby or Python bindings (neither interpreters use libtool to load their extensions, so they won't be even knowing the .la file is around, and you cannot *link* against those), or PAM modules (no implementation of PAM uses libtool to load the modules, so even here the .la files won't be considered at all). While these don't cause the kind of headaches .la files are known for (as you won't be linking against them to begin with), they are polluting the live filesystem as well as increasing the work for the analysis of those .la files that you link against. Please consider deleting them in the ebuild, after the make install is called. Further note: when these files are around, it's not uncommon for the packages to mistakenly build and install static archives (.a) files as well, even if these are modules that are only loaded from dynamic ELF files. If that is the case, *don't delete those after install*; instead follow the documentation I wrote at http://www.flameeyes.eu/autotools-mythbuster/libtool/index.html#libtool.plugins.dlopen to fix the packages so that only the shared object file is built (you still need to delete the .la file after install). This way you don't bother installing them and shorten the build time (as the static and shared versions are built with different flags which cause each source file to be built twice). Thank you for your help on cleaning up this mess. Diego
Wrote patch, forwarded it upstream for the static archives If you want to fight the presence of the .la files, change how libtool works first. I'm not gonna do it one package at a time.
