As the description says, Gentoo does not support installing .la files when pkg-config files are provided by a package. We have to think a little on how to implement this (and possibly automatically check for the case) but already opening a bug to cover the discussion.
Well, presence of .pc file may be some assumption. It's not always right though, for instance ImageMagick installs .pc files, yet its plugin loader seems to require .la files.
(In reply to comment #1) > though, for instance ImageMagick installs .pc files, yet its plugin loader > seems to require .la files. But these .la files aren't installed in libdir, and they correspond to modules, not libraries. We are considering libraries only right now.
If you look at bug 366071 you'll find it's not good idea to remove /usr/$(get_libdir)/libfoo.la either when modules need to keep their .la files That's why ImageMagick empties dependency_libs in src_install() instead, avoiding the libcanberra mistake (bug 366071) Anyway this bug doesn't really block bug 382537 because it's up to the maintainers to watch out cases like these, and then use the 'all' argument in the remove_libtool_files() in autotools-utils.eclass And that is why I dislike the eclass in it's current form, half-fixing and adding USE=static-libs the packages is seriously distracting and making it more difficult to find out unmigrated packages... at least this should be really made known to people using the eclass.
(In reply to comment #3) > If you look at bug 366071 you'll find it's not good idea to remove > /usr/$(get_libdir)/libfoo.la either when modules need to keep their .la files > That's why ImageMagick empties dependency_libs in src_install() instead, > avoiding the libcanberra mistake (bug 366071) Ouch, indeed that one is harder. > Anyway this bug doesn't really block bug 382537 because it's up to the > maintainers to watch out cases like these, and then use the 'all' argument in > the remove_libtool_files() in autotools-utils.eclass > > And that is why I dislike the eclass in it's current form, half-fixing and > adding USE=static-libs the packages is seriously distracting and making it more > difficult to find out unmigrated packages... at least this should be really > made known to people using the eclass. I guess we could do the '.pc watch + cleanup' thing by default and add AUTOTOOLS_PRESERVE_LAFILES or sth like that when necessary. Or just watch for .la files in other directories and fix them as appropriate.
Created attachment 286179 [details] A simple test script to handle described behavior Ok, my first tests show there is a single .pc file on my system which uses '-lfoo-${version}'. We could use pkg-config to expand that but then we will have to DEPEND on it. That could be useful but I'm not sure if it is really expected. Or we can just assume that one package would be a side loss, and if it started to use autotools-utils at some point, it will have to call .la removal manually. Attaching my little test tool / proof-of-concept code.
Created attachment 286223 [details, diff] Patch to autotools-utils And here it is. It removes .la files even with USE=static-libs when: - a .pc file is installed referring to the same library, - they don't provide any libs nor linker flags. Although I'm not sure if we're going the right way. Looking at autoconf macros, they don't really handle static compiling with pkg-config right. I don't see '--static' passed anywhere so that means autoconf always get dynamic linking flags only. Are you sure about that .la removal mania?
Done now, let's see how it works.
