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:

... 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:

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:

(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]

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.

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._________________lxg.de – codebits and tech talk

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.

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.

(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:

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.

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.

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.

This brought up libpangomm which wasn't caught by @preserved-rebuild - after rebuilding that, I also had a clean system._________________backend.cpp:92:2: warning: #warning TODO - this error message is about as useful as a cooling unit in the arctic

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. _________________~amd64, OpenRC, FGLRX, KDE
Fitzcarraldo's blog

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._________________The manual said "Requires Windows7 or better" so I installed GNU/Linux...

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.

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

Code:

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.

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._________________reach out a little bit more to catch it (DON'T BELIEVE the advocate part under my user name)