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).
For net-im/pidgin (and its various plugins) I can now confirm
that .la files are not needed here, so we could remove them here.
I'll check more packages on that.
BTW: is there a way to teach revdep-rebuild to ignore .la files ?
cu
--
----------------------------------------------------------------------
Enrico Weigelt, metux IT service -- http://www.metux.de/
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
10-24-2010, 10:29 PM
Nathan Phillip Brink
Removing .la files
On Sun, Oct 24, 2010 at 09:57:33PM +0000, Duncan wrote:
> 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 use tommy's portage-multilib which doesn't install any .la files
unless if ``shouldnotlink=true' is found in the .la file. I think
that the only sorts of problems we've encountered are similar to bug
300256 (caused by Gentoo splitting up a package into multiple
ebuilds).
> 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.
This problem is found in an autoconf macro shipped with libtool itself: