Hi all users,
Some of you might have noticed, others might notice, a few would
probably not notice at all, that some Gentoo developers have started
removing the libtool archive files from packages that they maintain;
these changes have some times been applied to stable ebuilds as well,
but in all cases they won't be applied unless the package is re-emerged.
The reasoning behind this removal is too long to explain in this mail,
but you can find the start of it in [1], [2], and you can find some more
details in [3], [4] (yes these are all posts from my blog that I wrote
in the past few years). What matters to you (users) is that removing .la
files makes it less likely that unexpected libraries get linked in your
executables, even without --as-needed, or where --as-needed is not
working correctly.
If it sounds familiar as a situation, you might have gone through the
now-infamous libpng14 upgrade earlier this year [5], [6].
Removing .la files can cause, though, temporary disruption in the build
processes of libraries depending on those involved, because of the
transitive nature of .la files. For instance you could experiences
something like this:
libtool: link: `/usr/lib/libdbus-1.la' is not a valid libtool archive
with libdbus-1.la being replaced by other library names. If this is the
case, _do not panic_! Nothing is irremediably broken and nothing will
have to be rebuilt!
First of all, you should install lafilefixer and let it pass through the
currently-installed system:
# emerge lafilefixer
# lafilefixer --justfixit
This will convert the references to libtool archives to the -llibname
form, which works both with and without them.
Secondly, you can avoid any future requirement for this by sanitising
the newly installed .la files; this can be done either by using the
(currently testing) Portage 2.1.9 series, or by adding the following
snippet to your /etc/portage/bashrc:
post_src_install() {
lafilefixer ${D}
}
(Users of the bashrcng feature can install a specific plugin to do the
job, I don't remember the name of it though, sorry!)
It's a one time process that _will_ save you from more breakage and work
to do in the future, so please bear with us.
Note: removal of .la files altogether from the system is _not_ possible
and _is_ going to break your system. This is why we've got to handle
this process with care and can't simply nuke them entirely. A few
packages (imagemagick, mpg123) actually use the .la files to load their
plugins; the libtool macros to detect libltld also rely on the presence
of $libdir/libltdl.la (even though it's not really necessary). Plus I
know of at least one package that installs data files with .la extension
even though they are not libtool archives.
Note #2: if you run revdep-rebuild before the above process, it _will_
find you a lot of packages to rebuild, and you'll waste a huge amount of
time running in circles.
At this time it is unclear what the path forward will be, if we either
keep removing .la files from packages, caring about the fact they are
not needed, and causing these disruption for who hasn't gone through the
above-noted process yet, or if we'll be doing a mass-removal and deal
separately with eventual breakage on packages that use them, like those
noted above. Both approaches have advantages and disadvantages and it's
mostly a matter of opinion and taste which one is better.
We'll be looking forward to make this more widely available knowledge
and we hope to be able to provide a better experience for all of you at
the end of this (bumpy) journey.
Thanks!
[1] http://blog.flameeyes.eu/2008/04/14/what-about-those-la-files
[2] http://blog.flameeyes.eu/s/lafiles-2
[3] http://blog.flameeyes.eu/s/lafiles-plugins
[4] http://blog.flameeyes.eu/s/lafiles-chart
[5] http://blog.flameeyes.eu/2010/05/12/gentoo-failed-us-again
[6] http://blog.flameeyes.eu/2010/06/29/stable-users-libpng-update
--
Diego Elio Pettenò — “Flameeyes”
http://blog.flameeyes.eu/
If you found a .asc file in this mail and know not what it is,
it's a GnuPG digital signature: http://www.gnupg.org/
signature.asc
Description: This is a digitally signed message part
