[gentoo-user] Re: Updating libpng: another libtool cockup?

[walt <w41ter@gmail.com>]

On 09/19/2011 07:10 AM, Alan McKinnon wrote:
> On Mon, 19 Sep 2011 03:06:30 -0700
> walt <w41ter@gmail.com> wrote:
> 
>> On Mon, 2011-09-19 at 01:39 +0200, Alan McKinnon wrote:
>>> On Sun, 18 Sep 2011 17:58:14 -0400
>>> Allan Gottlieb <gottlieb@nyu.edu> wrote:
>>>
>>>> On Sun, Sep 18 2011, walt wrote:
>>>>
>>>>> I just did a routine update on my ~amd64 machine and saw the
>>>>> portage warning that libpng14 has been replaced by libpng15,
>>>>> and I should run revdep-rebuild --library
>>>>> '/usr/lib/libpng14.so' and then delete the obsolete library.
>>>>>
>>>>> After that I ran plain revdep-rebuild as I do after every
>>>>> update, and saw that two gnome packages failed to rebuild
>>>>> properly because lpng14 couldn't be found :/
>>>>>
>>>>> From painful experience I've learned that good-old libtool files
>>>>> (*.la) are the usual suspects, and grep found -lpng14 in about
>>>>> ten .la files even after both revdep-rebuilds.  Grrr!
>>>>>
>>>>> This fixed the problem for me (as similar moves have done in the
>>>>> past):
>>>>>
>>>>> #find /usr/lib64 -name \*.la -exec sed -i s/png14/png15/ '{}'
>>>>> ';'
>>>>
>>>> Thanks for the tip.  I wonder when a routing update world tells
>>>> you to run
>>>>    revdep-rebuild --library <some-lib>
>>>> should you run it before or after the normal
>>>>    revdep-rebuild
>>>> that we normally run after updates?
>>>
>>> Neither. 
>>>
>>> revdep-rebuild checks everything, revdep-rebuild --library
>>> checks just some things.
>>>
>>> ebuilds sometimes issue messages to check just the libraries known
>>> to have been updated, but a full revdep-rebuild after an update
>>> will catch those anyway.
>>
>> Until recently I skipped the "--library" step exactly because I knew
>> revdep-rebuild will find and fix the broken packages after I delete
>> the old library.  So, why bother with the --library step, right?
>>
>> However.  A few weeks ago I got caught when I deleted one of those
>> obsolete libraries and only then did I find out that gcc is one of
>> the packages that depend on it :(
>>
>> I don't skip the --library step any more.
> 
> That's odd behaviour, I wonder what caused the difference.
> 
> Surely revdep-rebuild itself can't do this different just because you
> specified a library to compare? I wonder if that lib was maybe in the
> revdep-rebuild exclude list.
> 
> I'd be interested to track it down for reference, do you remember the
> library involved?

I think it may have been one of the libs pulled in by the graphite
useflag, like ppl or cloog-ppl, but I can't recall the details.  I
imagine most people wouldn't be affected because most people don't
set that flag, I'd guess.

Remember, I updated the system and deleted the obsolete lib *before*
I ran revdep-rebuild -- and then revdep-rebuild failed because gcc
couldn't build *anything* after that.  I should have moved the lib
to /tmp instead of deleting it.  Recovery would have been trivial.