Enrico Weigelt posted on Sun, 24 Oct 2010 22:09:30 +0200 as excerpted: > I'm doing some investigation on which .la files are still needed and > which are not. In general, .la files only are in use by very few > packages which use them to load plugins (I've seen no package which > actually requires them for compile-time importing in production).
FWIW, flameeyes has done quite a bit of work on this, but I'm not sure it's published anywhere. FWIW2, I recently took the big jump myself, PKG_INSTALL_MASKing *.la files (I run FEATURES=buildpkg so that's effectively install-masking them too, but they don't get in the binpkgs at all that way), then rebuilding my entire system, and while it's /possible/ certain plugins don't work, I've not noticed it. I needed only one exception, sys-devel/libtool itself. At least one package (IIRC imagemagick but I could be recalling incorrectly) tests for a properly configured libtool in the configure script by testing for libtool's single *.la file, libltdl.la, so I had to rebuild/reinstall libtool itself without that mask. I handled it using /etc/portage/env/sys-devel/libtool, which contains only the single setting: PKG_INSTALL_MASK= thus undoing the make.conf setting of: # dump *.la files PKG_INSTALL_MASK="*.la" So as of now: $ equery b -f '.*\.la$' * Searching for .*\.la$ ... sys-devel/libtool-2.2.10 (/usr/lib64/libltdl.la) $ That's it! =:^) Of course, the rebuild process likely wouldn't have gone so smoothly if I hadn't already had lafilefixer hooked even before FEATURES=fixlafiles (and was running --as-needed in LDFLAGS before that), with the system only recently entirely rebuilt when I upgraded to gcc-4.5, so there weren't any nasties in the existing *.la files to snag the rebuild. =:^) -- Duncan - List replies preferred. No HTML msgs. "Every nonfree program has a lord, a master -- and if you use the program, he is your master." Richard Stallman
