FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Gentoo > Gentoo User

 
 
LinkBack Thread Tools
 
Old 09-19-2011, 02:36 PM
Michael Mol
 
Default Updating libpng: another libtool cockup?

On Mon, Sep 19, 2011 at 10:20 AM, Allan Gottlieb <gottlieb@nyu.edu> wrote:
> On Mon, Sep 19 2011, Alan McKinnon wrote:
>>> > 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?
>
> It occurs exactly in the case we are discussing libpng
>
> ajglap gottlieb # revdep-rebuild; revdep-rebuild --library '/usr/lib64/libpng14.so.14'
> ** Configuring search environment for revdep-rebuild
>
> ** Checking reverse dependencies
> ** Packages containing binaries and libraries broken by a package update
> ** will be emerged.
>
> ** Collecting system binaries and libraries
> ** Generated new 1_files.rr
> ** Collecting complete LD_LIBRARY_PATH
> ** Generated new 2_ldpath.rr
> ** Checking dynamic linking consistency
> [ 100% ]
>
> ** Dynamic linking on your system is consistent... All done.
> ** Configuring search environment for revdep-rebuild
>
> ** Checking reverse dependencies
> ** Packages containing binaries and libraries using /usr/lib64/libpng14.so.14
> ** will be emerged.
>
> ** Collecting system binaries and libraries
> ** Generated new 1_files.rr
> ** Checking dynamic linking
> [ 8% ] ** * found /usr/bin/dia
> [ 46% ] ** * found /usr/lib64/dia/libaadl_objects.so
> ** * found /usr/lib64/dia/libart_filter.so
> ** * found /usr/lib64/dia/libcairo_filter.so
> ** * found /usr/lib64/dia/libcgm_filter.so
> ** * found /usr/lib64/dia/libchronogram_objects.so
> ** * found /usr/lib64/dia/libcustom_lines_objects.so
> ** * found /usr/lib64/dia/libcustom_objects.so
> ** * found /usr/lib64/dia/libdb_objects.so
> ** * found /usr/lib64/dia/libdia.so
> ** * found /usr/lib64/dia/libdxf_filter.so
> ** * found /usr/lib64/dia/liber_objects.so
> ** * found /usr/lib64/dia/libflowchart_objects.so
> ** * found /usr/lib64/dia/libfs_objects.so
> ** * found /usr/lib64/dia/libgrafcet_objects.so
> ** * found /usr/lib64/dia/libhpgl_filter.so
> ** * found /usr/lib64/dia/libistar_objects.so
> ** * found /usr/lib64/dia/libjackson_objects.so
> ** * found /usr/lib64/dia/libkaos_objects.so
> ** * found /usr/lib64/dia/libmetapost_filter.so
> ** * found /usr/lib64/dia/libmisc_objects.so
> ** * found /usr/lib64/dia/libnetwork_objects.so
> ** * found /usr/lib64/dia/libpgf_filter.so
> ** * found /usr/lib64/dia/libpixbuf_filter.so
> ** * found /usr/lib64/dia/libpostscript_filter.so
> ** * found /usr/lib64/dia/libpstricks_filter.so
> ** * found /usr/lib64/dia/libpython_plugin.so
> ^C * * ...terminated. Removing incomplete 3_broken.rr 3_errors.rr.

Is there no automated way to catch these? --library expects an
argument; how do I know which libraries to feed it?

--
:wq
 
Old 09-19-2011, 03:07 PM
walt
 
Default Updating libpng: another libtool cockup?

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.
 
Old 09-19-2011, 03:49 PM
David W Noon
 
Default Updating libpng: another libtool cockup?

On Mon, 19 Sep 2011 16:10:02 +0200, Alan McKinnon wrote about Re:
[gentoo-user] Re: Updating libpng: another libtool cockup?:

> On Mon, 19 Sep 2011 03:06:30 -0700
> walt <w41ter@gmail.com> wrote:
[snip]
> > I don't skip the --library step any more.
>
> That's odd behaviour, I wonder what caused the difference.

I guess your graph theory is out to lunch today. ... :-)

The problem is portage determining the dependency graph, but ebuilds do
not contain enough information to do this thoroughly. The best
example, at least in my memory, was the libexpat upgrade about 4 years
ago that trashed everybody's system -- many resorted to complete
re-installation.

At the end of that upgrade, there was an instruction to preform a
revdep-rebuild specifically for libexpat.so. Now, this upgrade
coincided with a full upgrade to KDE plus a full upgrade to GNOME, all
on the same day. As a result, the message to do a revdep-rebuild
specifically on libexpat was buried in other bumpf, plus there was other
library breakage out the yin-yang -- an extremely large yin-yang. It
was a sysadmin's perfect storm.

Doing a simple revdep-rebuild, with no library constraint, caused
ebuild breakage by the mile. This was because the subroutines in
libexpat are used inside ebuild processing by documentation utilities
such as ghostscript, xsltproc, etc.

OTOH, if one did a specific revdep-rebuild on libexpat, all of those
documentation utilities would be rebuilt before the main
revdep-rebuild. After that, the ebuilds all went smoothly.

Unfortunately, Portage does not have enough information to infer these
deep dependencies. This means it cannot schedule the more fundamental
revdep-rebuild ahead of those that depend upon it. We have to do that
by hand.

I hope this has explained why we should take messages about running
"revdep-rebuild --library libXXX" seriously.
--
Regards,

Dave [RLU #314465]
*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*
dwnoon@ntlworld.com (David W Noon)
*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*
 
Old 09-19-2011, 08:33 PM
Mark Knecht
 
Default Updating libpng: another libtool cockup?

On Mon, Sep 19, 2011 at 7:36 AM, Michael Mol <mikemol@gmail.com> wrote:
> On Mon, Sep 19, 2011 at 10:20 AM, Allan Gottlieb <gottlieb@nyu.edu> wrote:
<SNIP>
>> ajglap gottlieb # revdep-rebuild; revdep-rebuild --library '/usr/lib64/libpng14.so.14'
<SNIP>
>
> Is there no automated way to catch these? --library expects an
> argument; how do I know which libraries to feed it?
>
> --
> :wq

My question exactly. It's not likeyou can look at just names of
libraries as I think to do this right you've got to look at every
revision of every library on the system, don't you?

It's possible that this problem could exist for a long while if a
program doesn't get used much...

- Mark
 
Old 09-19-2011, 08:41 PM
Michael Mol
 
Default Updating libpng: another libtool cockup?

On Mon, Sep 19, 2011 at 4:33 PM, Mark Knecht <markknecht@gmail.com> wrote:
> On Mon, Sep 19, 2011 at 7:36 AM, Michael Mol <mikemol@gmail.com> wrote:
>> On Mon, Sep 19, 2011 at 10:20 AM, Allan Gottlieb <gottlieb@nyu.edu> wrote:
> <SNIP>
>>> ajglap gottlieb # revdep-rebuild; revdep-rebuild --library '/usr/lib64/libpng14.so.14'
> <SNIP>
>>
>> Is there no automated way to catch these? --library expects an
>> argument; how do I know which libraries to feed it?
>
> My question exactly. It's not likeyou can look at just names of
> libraries as I think to do this right you've got to look at every
> revision of every library on the system, don't you?
>
> It's possible that this problem could exist for a long while if a
> program doesn't get used much...

Based on subsequent discussion since I wrote that question, I think
the answer is, "currently, no." Ebuillds would need more metadata, and
portage would need to be more aware of deep dependencies.

I'm not sure of revdep-rebuild's angle, or how it might be able to be
improved to detect errors that don't come from broken linkage.
--
:wq
 
Old 09-19-2011, 08:52 PM
Mark Knecht
 
Default Updating libpng: another libtool cockup?

On Mon, Sep 19, 2011 at 1:41 PM, Michael Mol <mikemol@gmail.com> wrote:
> On Mon, Sep 19, 2011 at 4:33 PM, Mark Knecht <markknecht@gmail.com> wrote:
>> On Mon, Sep 19, 2011 at 7:36 AM, Michael Mol <mikemol@gmail.com> wrote:
>>> On Mon, Sep 19, 2011 at 10:20 AM, Allan Gottlieb <gottlieb@nyu.edu> wrote:
>> <SNIP>
>>>> ajglap gottlieb # revdep-rebuild; revdep-rebuild --library '/usr/lib64/libpng14.so.14'
>> <SNIP>
>>>
>>> Is there no automated way to catch these? --library expects an
>>> argument; how do I know which libraries to feed it?
>>
>> My question exactly. It's not likeyou can look at just names of
>> libraries as I think to do this right you've got to look at every
>> revision of every library on the system, don't you?
>>
>> It's possible that this problem could exist for a long while if a
>> program doesn't get used much...
>
> Based on subsequent discussion since I wrote that question, I think
> the answer is, "currently, no." Ebuillds would need more metadata, and
> portage would need to be more aware of deep dependencies.
>
> I'm not sure of revdep-rebuild's angle, or how it might be able to be
> improved to detect errors that don't come from broken linkage.
> --
> :wq

OK, I saw that comment but didn't grasp that it's the answer. Could be.

Alternatively, in Michael's example earlier, I don't think the ldd
results for bash are changed (are they?) when ncurses is updated:

Quote:
$ ldd /bin/bash
linux-vdso.so.1 => (0x00007fffbafff000)
libncurses.so.5 => /lib64/libncurses.so.5 (0x00007f0a4c278000)
libdl.so.2 => /lib64/libdl.so.2 (0x00007f0a4c074000)
libc.so.6 => /lib64/libc.so.6 (0x00007f0a4bce4000)
/lib64/ld-linux-x86-64.so.2 (0x00007f0a4c4ce000)
It seems to me this is tending toward something similar to slots,
isn't it? If one package (bash) needs a specific version then can't we
find it using ldd (on every package on the system unfortunately) and
ensure that the needed .so files aren't removed?

/lib64/libncurses.so.5 & /lib64/libncurses.so.6 could both exist on
the system even if both version of the ncurses package don't.

I suspect this is mostly what revdep-rebuild is already doing, and I
also suspect my view of the problem is far too remedial...

Thanks,
Mark
 
Old 09-19-2011, 08:54 PM
Peter Humphrey
 
Default Updating libpng: another libtool cockup?

On Monday 19 September 2011 16:49:55 David W Noon wrote:




> I hope this has explained why we should take messages about running

> "revdep-rebuild --library libXXX" seriously.




Well, you have me convinced. I had assumed that a bland revdep-rebuild would catch everything including the library specified. Wrong, I see.




--

Rgds

Peter Linux Counter 5290, 1994-04-23
 
Old 09-19-2011, 09:04 PM
Nikos Chantziaras
 
Default Updating libpng: another libtool cockup?

On 09/18/2011 11:10 PM, 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.


Oh crap. I somehow missed that (and I try to always read the logs with
'elog'). But this somehow skipped past my radar. I still have
libpng14.so in /usr/lib. revdep-rebuild lists about 80 packages needing
a rebuild.


Is there a way to check the system whether old libraries are still around?
 
Old 09-19-2011, 09:10 PM
Michael Schreckenbauer
 
Default Updating libpng: another libtool cockup?

On Monday, 19. September 2011 13:52:26 Mark Knecht wrote:
> On Mon, Sep 19, 2011 at 1:41 PM, Michael Mol <mikemol@gmail.com> wrote:
> > On Mon, Sep 19, 2011 at 4:33 PM, Mark Knecht <markknecht@gmail.com> wrote:
> >> On Mon, Sep 19, 2011 at 7:36 AM, Michael Mol <mikemol@gmail.com> wrote:
> >>> On Mon, Sep 19, 2011 at 10:20 AM, Allan Gottlieb <gottlieb@nyu.edu>
wrote:
> >> <SNIP>
> >>
> >>>> ajglap gottlieb # revdep-rebuild; revdep-rebuild --library
> >>>> '/usr/lib64/libpng14.so.14'>>
> >> <SNIP>
> >>
> >>> Is there no automated way to catch these? --library expects an
> >>> argument; how do I know which libraries to feed it?
> >>
> >> My question exactly. It's not likeyou can look at just names of
> >> libraries as I think to do this right you've got to look at every
> >> revision of every library on the system, don't you?
> >>
> >> It's possible that this problem could exist for a long while if a
> >> program doesn't get used much...
> >
> > Based on subsequent discussion since I wrote that question, I think
> > the answer is, "currently, no." Ebuillds would need more metadata, and
> > portage would need to be more aware of deep dependencies.
> >
> > I'm not sure of revdep-rebuild's angle, or how it might be able to be
> > improved to detect errors that don't come from broken linkage.
> > --
> >
> > :wq
>
> OK, I saw that comment but didn't grasp that it's the answer. Could be.
>
> Alternatively, in Michael's example earlier, I don't think the ldd
> results for bash are changed (are they?) when ncurses is updated:
>
>
Quote:
> $ ldd /bin/bash
> linux-vdso.so.1 => (0x00007fffbafff000)
> libncurses.so.5 => /lib64/libncurses.so.5 (0x00007f0a4c278000)
> libdl.so.2 => /lib64/libdl.so.2 (0x00007f0a4c074000)
> libc.so.6 => /lib64/libc.so.6 (0x00007f0a4bce4000)
> /lib64/ld-linux-x86-64.so.2 (0x00007f0a4c4ce000)
>
They would change to

$ ldd /bin/bash
linux-vdso.so.1 => (0x00007fffbafff000)
libncurses.so.5 => not found
libdl.so.2 => /lib64/libdl.so.2 (0x00007f0a4c074000)
libc.so.6 => /lib64/libc.so.6 (0x00007f0a4bce4000)
/lib64/ld-linux-x86-64.so.2 (0x00007f0a4c4ce000)

if the ebuild maintainer forgets to keep the *.so.5 version on the system in
the *.so.6 update. That results in a broken bash.

> It seems to me this is tending toward something similar to slots,
> isn't it? If one package (bash) needs a specific version then can't we
> find it using ldd (on every package on the system unfortunately) and
> ensure that the needed .so files aren't removed?

That's what ebuild maintainers do, afaik.

~ $ equery b /usr/lib64/libpng14.so.14
* Searching for /usr/lib64/libpng14.so.14 ...
media-libs/libpng-1.5.4 (/usr/lib64/libpng14.so.14)

See? libpng14 is part of png-1.5.x package, so libpng14 is not removed, when
you install the 1.5.x version. That keeps programs going.

> /lib64/libncurses.so.5 & /lib64/libncurses.so.6 could both exist on
> the system even if both version of the ncurses package don't.

That's right. But keep in mind, that the old lib is outdated. Bugs remain
bugs, nothing is fixed. Getting fixes, is why we update after all, isn't it?

> I suspect this is mostly what revdep-rebuild is already doing, and I
> also suspect my view of the problem is far too remedial...
>
> Thanks,
> Mark

Best,
Michael
 
Old 09-19-2011, 09:28 PM
Mark Knecht
 
Default Updating libpng: another libtool cockup?

On Mon, Sep 19, 2011 at 2:10 PM, Michael Schreckenbauer <grimlog@gmx.de> wrote:
> On Monday, 19. September 2011 13:52:26 Mark Knecht wrote:
<SNIP>
>
>> /lib64/libncurses.so.5 & /lib64/libncurses.so.6 could both exist on
>> the system even if both version of the ncurses package don't.
>
> That's right. But keep in mind, that the old lib is outdated. Bugs remain
> bugs, nothing is fixed. Getting fixes, is why we update after all, isn't it?
>

Right, but better that I have a bug until the next update that fixes
this than a system that doesn't work because bash crashes, right?

I was only thinking very short term and not that the ebuild maintainer
shouldn't eventually get things right with all bug fixes.

Thanks for getting this issue out there today. It's been very helpful
to have you along!

Cheers,
Mark
 

Thread Tools




All times are GMT. The time now is 04:58 AM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org