Apparently, though unproven, at 16:17 on Thursday 19 May 2011, Paul Hartman 
did opine thusly:

> On Wed, May 18, 2011 at 4:53 PM, Mick <michaelkintz...@gmail.com> wrote:
> > On Wednesday 18 May 2011 22:28:38 Alan McKinnon wrote:
> >> Apparently, though unproven, at 23:06 on Wednesday 18 May 2011, Mick did
> >> opine
> >> 
> >> thusly:
> >> > Had a depclean session which removed:
> >> >  media-libs/musicbrainz
> >> > 
> >> >     selected: 2.1.5
> >> > 
> >> >    protected: none
> >> > 
> >> >      omitted: 3.0.2
> >> > 
> >> > Then I followed up with revdep-rebuild and this comes up:
> >> >  * Generated new 1_files.rr
> >> >  * Collecting complete LD_LIBRARY_PATH
> >> >  * Generated new 2_ldpath.rr
> >> >  * Checking dynamic linking consistency
> >> > 
> >> > [ 67% ]  *   broken /usr/lib/libtunepimp.la (requires -lmusicbrainz)
> >> > [snip ...]
> >> > 
> >> >  * Assigning files to packages
> >> >  *  !!! /usr/lib/libtunepimp.la not owned by any package is broken !!!
> >> >  *   /usr/lib/libtunepimp.la -> (none)
> >> > 
> >> > What is "-lmusicbrainz" and is it telling me to just delete
> >> > /usr/lib/libtunepimp.la?
> >> 
> >> Look into any *.la file and you will see stuff like this:
> >> 
> >> /usr/lib/libsqlite3.la:dependency_libs=' -ldl -lpthread'
> >> 
> >> The .la files are hints to the linker telling it how to do stuff, the -l
> >> bits reference libraries that will be needed. Far more often than is
> >> acceptable, libtool cocks this up in spectacular ways, which is why we
> >> had
> >> 
> >> lafilefixer --justfixit
> >> 
> >> for so long, and why it is now built into portage.
> >> 
> >> I have musicbrainz, but I do not have /usr/lib/libtunepimp.la and yours
> >> is orphaned anyway - it probably got left behind long ago when depclean
> >> didn't know it was related to musicbrainz.
> >> 
> >> Just delete the thing, be done with it, revdep-rebuild will stfu and you
> >> will be a much happier chappy
> > 
> > Thanks guys, it's been blitzed!
> 
> I think the long-term plan is to eliminate the *.la files entirely,
> once all packages have been updated as such by their maintainers, so
> hopefully this kind of problem will vanish in the not-too-distant
> future. :)

It's closer than you might think, there are very few packages left to be 
fixed:

http://blog.flameeyes.eu/2011/05/03/surviving-without-libtool-archives

-- 
alan dot mckinnon at gmail dot com

Reply via email to