libpng-1.5.x entered stable - upgrade tips

[Polynomial-C]

Hi folks,

now that libpng-1.5.x was unmasked I found my systems being unable to do a straightforward upgrade to that new version.
In my case this was caused by some .la files still containing -lpng14 so here's a small hint how to get rid of errors like:

Code: Select all

... cannot find -lpng14...

First make sure you already did the upgrade steps the libpng-1.5.x ebuilds are suggesting. If you want to have as much fixed as possible with the first run, modify the command suggested by the ebuild as follows:

Code: Select all

revdep-rebuild --library '/usr/lib64/libpng14.so.14' -- --keep-going

When this command has finished you should already have most of the packages being fixed and linked against libpng-1.5.x. Now to the -lpng14 problem. Run the following command to get rid of those:

Code: Select all

emerge -1av --keep-going $(find /usr \( -name "*.la" -o -name "*.pc" -o -name "*-config" -o -name "*.pm" \) -exec grep -H png14 {} \; | cut -d : -f 1 | xargs qfile -CSq | sort | uniq)

(qfile belongs to app-portage/portage-utils package so make sure to have it installed before running this command).
2011-Oct-18: IMPORTANT! The combination of find and grep in our stable tree seems to have trouble with multiple filename patterns finding files containing a specific string[1]. I modified the command to circumvent this problem. All stable users are encouraged to repeat the search with the modified command.
Simply run the revdep-rebuild command again and all should be settled. If no more compile errors occur you may remove the old /usr/lib64/libpng14.so.14 from your system.
If you still have compile errors try to run the above command several times until all errors are gone.
In case emerge prints some error message like "emerge: error: no such option: -," the find command didn't find anything containing png14 and thus emerge got called with an invalid parameter. This doesn't hurt your system and should just be considered some "cosmetic disadvantage" of the above command

[edit]
UPDATE1! Package slots should now be taken into account as well. Added "--keep-going" option to last one-liner.
UPDATE2! Added some more files to the find search. Now .la files and *-config files are taken into account, too.
UPDATE3! Adjusted summary to reflect png15 being in stable now.
UPDATE4! Added a comment about emerge printing an error message when the find command doesn't find anything containing png14.
UPDATE5! Added perl modules to the find search.
UPDATE6! Modified the find command to circumvent a problem with stable find/grep combination.
[/edit]

[1] Thanks mephinet for giving the correct hints.

[mod]"Sticking" thread - Jorge (jmbsvicetto)[/mod]

[asturm]

wohoo, I sense adventures ahead

[krinn]

In my case this was caused by some .la files still containing -lpng14

A nice proof devs are speaking with each other.... :/
http://forums.gentoo.org/viewtopic-t-873099.html

And instead of providing that hack, you might get in touch with ssuominen to get the failing packages fix.
Not saying i'm not happy to get that fix for unstable users, but getting the packages that fail fix will help more stable users to avoid more troubles if possible.

[lxg]

Code: Select all

emerge -1av $(find /usr -name "*.la" -exec grep -H png14 {} \; | cut -d : -f 1 | xargs qfile -Cq | sort | uniq)

This works for the most of the packages, only dev-python/pygtksourceview and x11-libs/gtksourceview fail. I can build x11-libs/gtksourceview, but the build of dev-python/pygtksourceview fails. When I run find /usr -name "*.la" -exec grep -H png14 {} \; | cut -d : -f 1 | xargs qfile -Cq | sort | uniq again, it always brings up those two packages.

[omidxo]

Code: Select all

emerge -1av $(find /usr -name "*.la" -exec grep -H png14 {} \; | cut -d : -f 1 | xargs qfile -Cq | sort | uniq)

This works for the most of the packages, only dev-python/pygtksourceview and x11-libs/gtksourceview fail. I can build x11-libs/gtksourceview, but the build of dev-python/pygtksourceview fails. When I run find /usr -name "*.la" -exec grep -H png14 {} \; | cut -d : -f 1 | xargs qfile -Cq | sort | uniq again, it always brings up those two packages.

Which SLOT is x11-libs/gtksourceview?

Code: Select all

emerge -1av $(find /usr -name "*.la" -exec grep -H png14 {} \; | cut -d : -f 1 | xargs qfile -Cq | sort | uniq)

These are the packages that would be merged, in order:

Calculating dependencies... done!
[ebuild   R    ] dev-python/pygtksourceview-2.10.1  USE="-debug -doc" 0 kB
[ebuild   R    ] media-libs/clutter-gtk-1.0.2  USE="introspection -debug -doc -examples" 0 kB
[ebuild   R    ] x11-libs/gtksourceview-3.0.5-r1  USE="introspection -doc -glade -test" 0 kB
[ebuild   R    ] app-editors/gedit-plugins-2.32.0  USE="python -charmap -synctex -terminal" 0 kB

Total: 4 packages (4 reinstalls), Size of downloads: 0 kB

Would you like to merge these packages? [Yes/No] no

x11-libs/gtksourceview-3.0.5-r1 is wrong.

Type

Code: Select all

emerge pygtksourceview clutter-gtk =gtksourceview-2.10.5-r1 gedit-plugins -1D

Every is ok.

[omidxo]

Maybe clutter-gtk should be clutter-gtk-0.10.8 too.

[Timbers2k]

Code: Select all

emerge -1av $(find /usr -name "*.la" -exec grep -H png14 {} \; | cut -d : -f 1 | xargs qfile -Cq | sort | uniq)

This works for the most of the packages, only dev-python/pygtksourceview and x11-libs/gtksourceview fail. I can build x11-libs/gtksourceview, but the build of dev-python/pygtksourceview fails. When I run find /usr -name "*.la" -exec grep -H png14 {} \; | cut -d : -f 1 | xargs qfile -Cq | sort | uniq again, it always brings up those two packages.

Which SLOT is x11-libs/gtksourceview?

Code: Select all

emerge -1av $(find /usr -name "*.la" -exec grep -H png14 {} \; | cut -d : -f 1 | xargs qfile -Cq | sort | uniq)

These are the packages that would be merged, in order:

Calculating dependencies... done!
[ebuild   R    ] dev-python/pygtksourceview-2.10.1  USE="-debug -doc" 0 kB
[ebuild   R    ] media-libs/clutter-gtk-1.0.2  USE="introspection -debug -doc -examples" 0 kB
[ebuild   R    ] x11-libs/gtksourceview-3.0.5-r1  USE="introspection -doc -glade -test" 0 kB
[ebuild   R    ] app-editors/gedit-plugins-2.32.0  USE="python -charmap -synctex -terminal" 0 kB

Total: 4 packages (4 reinstalls), Size of downloads: 0 kB

Would you like to merge these packages? [Yes/No] no

x11-libs/gtksourceview-3.0.5-r1 is wrong.

Type

Code: Select all

emerge pygtksourceview clutter-gtk =gtksourceview-2.10.5-r1 gedit-plugins -1D

Every is ok.

Why is x11-libs/gtksourceview-3.0.5-r1 wrong? It's the current version. We need to emerge an old version?

[lxg]

x11-libs/gtksourceview-3.0.5-r1 is wrong.

Good point!

Code: Select all

emerge -1q "<x11-libs/gtksourceview-3" dev-python/pygtksourceview

That did it.

[dufeu]

Now tho the -lpng14 problem. I ran the following command to get rid of those:

Code: Select all

emerge -1av $(find /usr -name "*.la" -exec grep -H png14 {} \; | cut -d : -f 1 | xargs qfile -Cq | sort | uniq)

(qfile belongs to app-portage/portage-utils package so make sure to have it installed before running this command).
Now simply run the revdep-rebuild command again and all should be settled. If no more compile errors occur you may remove the old /usr/lib64/libpng14.so.14 from your system.

First - thanks for posting this and the tip!

Second, - I did my normal every other week upgrade world process. This came back with approximately 50 packages to upgrade. The resulting 'emerge @preserved-rebuild' directive came back with 125 packages to rebuild. I used 'emerge --keep-going @preserved-rebuild'.

A number of packages still failed with '-libpng14' failures.

When I run the command you suggest, the following packages on my system are selected:

Code: Select all

rebuild   R    ] gnome-base/libgnomecanvas-2.30.3  USE="-doc -glade -test" 0 kB
[ebuild   R    ] dev-libs/guiloader-c++-2.21.0  USE="nls" LINGUAS="-ru" 0 kB
[ebuild   R    ] app-pda/gnome-pilot-2.32.1  USE="eds -debug" 0 kB
[ebuild   R    ] dev-cpp/libsexymm-0.1.9  USE="-debug -doc" 0 kB
[ebuild   R    ] dev-cpp/pangomm-2.28.2  USE="-doc" 0 kB
[ebuild   R    ] dev-libs/gdl-3.0.2  USE="introspection -doc" 0 kB
[ebuild   R    ] dev-python/pygoocanvas-0.14.1  USE="-doc -examples" 0 kB
[ebuild   R    ] dev-python/pygtksourceview-2.10.1  USE="-debug -doc" 0 kB
[ebuild   R    ] dev-vcs/giggle-0.5  USE="eds -debug" 0 kB
[ebuild   R    ] games-board/ggz-gtk-client-0.0.14.1  USE="-debug" 0 kB
[ebuild   R    ] gnome-base/libgnomekbd-2.32.0  USE="-test" 0 kB
[ebuild   R    ] gnome-extra/bug-buddy-2.32.0-r2  USE="eds" 0 kB
[ebuild   R    ] gnome-extra/gnome-media-2.32.0-r1  USE="pulseaudio" 0 kB
[ebuild   R    ] gnome-extra/gtkhtml-4.0.2  0 kB
[ebuild  NS    ] x11-libs/goocanvas-2.0.0 [1.0.0] USE="-doc -examples" 0 kB
[ebuild   R    ] x11-libs/gtksourceview-3.0.5-r1  USE="introspection -doc -glade -test" 0 kB
[ebuild   R    ] gnome-base/libgnomeui-2.24.5  USE="-doc -test" 0 kB
[ebuild   R    ] x11-libs/gtkglext-1.2.0  USE="-debug" 0 kB
[ebuild   R    ] dev-cpp/libgnomecanvasmm-2.26.0  USE="-debug -doc -examples" 0 kB
[ebuild   R    ] dev-util/crow-designer-2.21.0  USE="nls" LINGUAS="-ru" 0 kB
[ebuild   R    ] dev-cpp/gtkglextmm-1.2.0-r1  USE="-debug -doc" 0 kB
[ebuild   R    ] net-print/gnome-cups-manager-0.33-r2  USE="samba" 0 kB

When I tried to compile several of these individually, the individual packages I tried still failed with -lpng14 errors. Running this never got past the 'dev-libs/guiloader-c++-2.21.0' package.

However, if I may be so bold, perhaps a small modification {add the '--keep-going' option} to your tip is in order:

Code: Select all

emerge -1av --keep-going $(find /usr -name "*.la" -exec grep -H png14 {} \; | cut -d : -f 1 | xargs qfile -Cq | sort | uniq)

Depending on installed packages and individual existing installation issues there is, I believe, potential for circular dependency or ordering issues which will make any given packages installation success problematic.

What I did was take the above generated list and started attempting to install each one individually, the ones earlier in the list which failed would then be able to succeed.

More specificially, once I manually completed the libraries dealing with memory management ('mm' and 'canvas') packages, then packages like 'guiloader-c++' would complete whereas simply running the recommended order of packages would always fail. Just guessing, but perhaps pangomm and sexymm in particular?

Because 'emerge' selects random order when the correct emerge order can't be determined {due to conflicting/circular dependency issues}, different people will experience differing degrees of success. I will also note that this especially seems to be a problem with the 'gnome' universe of packages. {le sigh} So the above is not a surprise to me whatsoever.

In other words, because emerge order can't always be correctly determined, Polynomial-C's tip should probably be modified as suggested and don't be surprised if you need to run re-iteratively 1 or 2 additional times.

edit

I ended up executing:

Code: Select all

emerge -1q "<x11-libs/gtksourceview-3" dev-python/pygtksourceview
emerge -1av --keep-going $(find /usr -name "*.la" -exec grep -H png14 {} \; | cut -d : -f 1 | xargs qfile -Cq | sort | uniq)
emerge -1av --keep-going $(find /usr -name "*.la" -exec grep -H png14 {} \; | cut -d : -f 1 | xargs qfile -Cq | sort | uniq)
emerge -1av --keep-going $(find /usr -name "*.la" -exec grep -H png14 {} \; | cut -d : -f 1 | xargs qfile -Cq | sort | uniq)

I still have one package left with -lpng14' failure:

Code: Select all

>>> Failed to emerge dev-python/pygoocanvas-0.14.1

libtool: link:  x86_64-pc-linux-gnu-gcc -shared  .libs/goocanvasmodule_la-goocanvasmodule.o .libs/goocanvasmodule_la-goocanvas.o   /usr/lib64/libgoocanvas.so -L/usr/lib64 -lresolv -lpixman-1 /usr/lib64/libdirectfb.so -lpng14 /usr/lib64/libXrender.so -lexpat -lEGL /usr/lib64/libfusion.so /usr/lib64/libdirect.so -lX11 -lxcb /usr/lib64/libXau.so /usr/lib64/libXdmcp.so -ldl -lz -lGL -lm -lgtk-x11-2.0 -lgdk-x11-2.0 /usr/lib64/libatk-1.0.so -lpthread -lgio-2.0 -lpangoft2-1.0 -lpangocairo-1.0 -lgdk_pixbuf-2.0 -lpango-1.0 -lfreetype -lfontconfig -lgobject-2.0 -lgmodule-2.0 -lgthread-2.0 -lrt -lglib-2.0 -lcairo -lpython2.7  -pthread -march=opteron -Wl,-O1 -Wl,--as-needed -Wl,-O1 -pthread   -pthread -Wl,-soname -Wl,goocanvasmodule.so -Wl,-version-script -Wl,.libs/goocanvasmodule.ver -o .libs/goocanvasmodule.so
/usr/lib/gcc/x86_64-pc-linux-gnu/4.5.3/../../../../x86_64-pc-linux-gnu/bin/ld: cannot find -lpng14

Not being a programmer, I'm still trying different search strategies to stomp on this one. Suggestions welcome.

[gringo]

yeah, at least in my case @preserved-rebuild did quite a nice job but some more logic is needed in the way portage orders the package for merging, i mean, nautilus wouldnt build until cairo was rebuilt (IIRC) and so on.
it didnt catch all packages though and Polynomial-Cs trick showed 5 more packages that indeed were broken according to revdep-rebuild.

cheers

[dufeu]

I was unable to quash the 'pygoocanvas' issue so I cheated.

I approached the problem from the direction of "Do I actually need this?". I did an 'equery depends' check and it turned out I only need pygoocanvas for 'pitivi'. This is a video editor I was trying. Did an "emerge --depclean pitivi && emerge --depclean pygoocanvas" and successfully removed both packages.

I also, in the hopes that any possible regressions may have been found and fixed since I last did and 'emerge --sync', refreshed the portage tree. Indeed, there was a zlib regression effecting 'vlc'.

Everything is now up to date. There are no remaining @preserved-rebuild items. "emerge --depclean" reports no items to needing to be removed. All the '-lpng14' failures now appear to be resolve.

Huzzah.

[asturm]

Did you

Code: Select all

find /usr/lib/ -name '*.la' -exec grep png14 {} + 

?

This brought up libpangomm which wasn't caught by @preserved-rebuild - after rebuilding that, I also had a clean system.

[robbyjo]

These packages still fail to fix lpng14 error above despite all the tips in all forums:

Code: Select all

[ebuild   R    ] gnome-base/gnome-panel-2.32.1-r3  USE="bonobo eds introspection* networkmanager -doc" 0 kB
[ebuild   R    ] net-print/gnome-cups-manager-0.33-r2  USE="samba" 0 kB
[ebuild   R    ] app-office/dia-0.97.1  USE="cairo gnome python -debug -doc (-png%*) (-zlib%*)" 0 kB
[ebuild   R    ] gnome-base/gnome-settings-daemon-2.32.1-r2  USE="libnotify policykit pulseaudio smartcard -debug" 0 kB
[ebuild   R    ] media-gfx/pngcrush-1.7.17  0 kB
[ebuild   R    ] app-office/gnucash-2.4.7  USE="chipcard cxx doc hbci mysql ofx postgres python quotes webkit -debug -sqlite" 0 kB
[ebuild   R    ] dev-lang/R-2.13.1  USE="X bash-completion cairo java jpeg lapack nls openmp png readline tk -doc -minimal -perl* -profile -static-libs" 0 kB
[ebuild   R    ] gnome-extra/libgda-4.2.9  USE="berkdb gnome-keyring graphviz gtk introspection java ldap mysql postgres sourceview ssl -bindist -canvas -debug -doc (-firebird) -http -json -oci8" 0 kB

[asturm]

You should re-sync, R did build fine for me yesterday.

[robbyjo]

You're right. I just did and R compiled just fine. The rest do not, though. Thanks.

[Fitzcarraldo]

In my case the transition to 1.5.x was more painful than the transition to 1.4.x. My thanks go to Polynomial-C for his tips, to omidxo for reminding me that the couple of packages whose .la files I could not rid of the dreaded -lpng14 were slotted (I could kick myself for not realising sooner!), and to dufeu for mentioning pygoocanvas. I wonder in retrospect if the problem with pygoocanvas was due to goocanvas: I fixed that after removing pygoocanvas but, had I fixed goocanvas first, perhaps I would not have needed to remove pygoocanvas? Anyway, it's all good again now, after a couple of days of tinkering.

[Polynomial-C]

Thanks for all your feedback.
I've updated the last command in my original post so that slots are now taken into account and --keep-going is used there as well. This should at least help those people to not have this command failing over and over again because portage isn't correctly ordering the to be recompiled packages.

[dufeu]

Thanks for all your feedback.
I've updated the last command in my original post so that slots are now taken into account and --keep-going is used there as well. This should at least help those people to not have this command failing over and over again because portage isn't correctly ordering the to be recompiled packages.

Thank you! It was your original post which pointed me in the right direction to get a handle on solving my problems.

[toralf]

Althought OT

Code: Select all

find /usr/lib/ -name '*.la' -exec grep png14 {} + 

I prefer

Code: Select all

find /usr/lib/ -name '*.la' -print0 | xargs -0 grep -l png14

which should always be faster

[dufeu]

One last detail: If you execute the 'emerge $(find' command and receive the following:

Code: Select all

Usage: emerge [options]

emerge: error: no such option: -,

It means that no ".la" files which still wanted -lpng14 were found.

As it happened, all of my x86 based systems {which are, relatively speaking, lightly loaded with packages} did not have any packages needing -lpng14. Needless to say, I was perplexed by this for awhile.

[furanku]

Thanks a lot for these instructions!

I think this topic should be moved to "Documentation, Tips & Tricks" as it provides valuable and time-saving informations for all ~arch users.

[padoor]

Code: Select all

ramaswamy@localtux ~ $ su
Password:
localtux ramaswamy # emerge -1av $(find /usr -name "*.la" -exec grep -H png14 {} \; | cut -d : -f 1 | xargs qfile -Cq | sort | uniq)
Usage: emerge [options]

emerge: error: no such option: -,
localtux ramaswamy #

from above posts it was said no pckages need -libpng14
but i need it for graphviz
emrge error says

Code: Select all

CCLD   libgvplugin_gd_C.la 
   CCLD   libgvplugin_gd.la 
 /usr/lib/gcc/i686-pc-linux-gnu/4.5.3/../../../../i686-pc-linux-gnu/bin/ld: cannot find -lpng14 
 collect2: ld returned 1 exit status

what now?

[Polynomial-C]

Code: Select all

ramaswamy@localtux ~ $ su
Password:
localtux ramaswamy # emerge -1av $(find /usr -name "*.la" -exec grep -H png14 {} \; | cut -d : -f 1 | xargs qfile -Cq | sort | uniq)
Usage: emerge [options]

emerge: error: no such option: -,
localtux ramaswamy #

from above posts it was said no pckages need -libpng14
but i need it for graphviz
emrge error says

Code: Select all

CCLD   libgvplugin_gd_C.la 
   CCLD   libgvplugin_gd.la 
 /usr/lib/gcc/i686-pc-linux-gnu/4.5.3/../../../../i686-pc-linux-gnu/bin/ld: cannot find -lpng14 
 collect2: ld returned 1 exit status

what now?

Maybe this -lpng14 is coming from a pkgconfig file. You may try a slightly updated version of the one-liner:

Code: Select all

emerge -1av --keep-going $(find /usr -name "*.la" -o -name "*.pc" -exec grep -H png14 {} \; | cut -d : -f 1 | xargs qfile -CSq | sort | uniq)

Please report back if that helps so I can update my first post accordingly.

[SamuliSuominen]

Code: Select all

CCLD   libgvplugin_gd_C.la 
   CCLD   libgvplugin_gd.la 
 /usr/lib/gcc/i686-pc-linux-gnu/4.5.3/../../../../i686-pc-linux-gnu/bin/ld: cannot find -lpng14 
 collect2: ld returned 1 exit status

Maybe this -lpng14 is coming from a pkgconfig file.

It could be `gdlib-config --libs` so before building graphviz, you might need to execute `emerge -1 media-libs/gd`.

[padoor]

i think all above solutions apply to portage-2.2 users.
first i merged portage-2.2.0_alpha60
then downgraded/remerged libpng-1.4.8-r2
then i got

Code: Select all

ramaswamy@localtux ~ $ dir /usr/lib/libpng*
/usr/lib/libpng.so      /usr/lib/libpng14.so.14  /usr/lib/libpng15.so.15
/usr/lib/libpng12.so.0  /usr/lib/libpng15.so     /usr/lib/libpng15.so.15.5.0

after that graphviz merged ok
for libgdbm.so.3 i had to downgrade gdbm
now only i get preserved-rebuild libs
previous portage used to just remove old libs like lpng14 libgdbm.so.3 then i got into problems.
now it looks alright
thanks for reply
emerge -DNuav world picked up gdbm upgrade but not libpng15
probably nothing uses libpng15 in my system.