Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 319061 - media-libs/libpng-1.4.2 update not handled by preserved-libs due to uninstall of older SLOT
Summary: media-libs/libpng-1.4.2 update not handled by preserved-libs due to uninstall...
Status: RESOLVED DUPLICATE of bug 286714
Alias: None
Product: Portage Development
Classification: Unclassified
Component: Unclassified (show other bugs)
Hardware: All Linux
: High normal with 1 vote (vote)
Assignee: Portage team
URL:
Whiteboard:
Keywords:
Depends on:
Blocks: preserve-libs
  Show dependency tree
 
Reported: 2010-05-09 14:04 UTC by Jonathan Adamczewski
Modified: 2011-03-30 15:56 UTC (History)
25 users (show)

See Also:
Package list:
Runtime testing required: ---


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Jonathan Adamczewski 2010-05-09 14:04:33 UTC
With deceptive silence and ease, libpng-1.4.2 broke most of the interesting apps on my system.

No @preserved_rebuild, no note to revdep-rebuild, just broken build and broken apps.

Please add some kind of warning/instruction to this one, thanks.

Reproducible: Always

Steps to Reproduce:
Comment 1 Omar Saleem 2010-05-09 16:24:27 UTC
i can confirm this. the only way i was able to fix it was to reinstall libpng-1.2.43 (i don't think r1 or r2 matters, since apps complain about not having libpng12.so.0)
i have 1.2.43-r1 in :1.2 slot and 1.4.2 in :0 slot and things are currently broken because through an update libpng-1.4.2 got installed again (it oscillates between upgrading and downgrading libpng). 
so the way to fix this is to make sure 1.2.43-r1 or -r2 is the active installation of libpng, and i guess masking 1.4.2? 
on a related note, see http://bugs.gentoo.org/show_bug.cgi?id=319029
Comment 2 Gef 2010-05-09 18:14:20 UTC
As the two libs are sloted, this should not have broken anything on your install, strange.

On my ~amd64 system, I did :
emerge -Dvua world
emerge -a --depclean libpng:1.2

And nothing was unmerged, nor broken. =lib-1.2.43-r1 and =lib-1.4.2 are still installed. You may then proceed with re-emerging any app linked against libpng1.2, for example using something like the following:

revdep-rebuild -L /usr/lib/libpng12.so.0 -- -av1
Comment 3 Harald van Dijk (RETIRED) gentoo-dev 2010-05-09 18:35:17 UTC
(In reply to comment #0)
> No @preserved_rebuild,

I think FEATURES="preserve-libs" should have caught this. Reassigning to the portage folks.

(In reply to comment #2)
> As the two libs are sloted,

libpng-1.4.2 blocks <media-libs/libpng-1.2.43-r1, causing portage to uninstall the media-libs/libpng-1.2.43 that was available before.
Comment 4 Sebastian Luther (few) 2010-05-09 18:52:13 UTC
(In reply to comment #3)
> (In reply to comment #0)
> > No @preserved_rebuild,
> 
> I think FEATURES="preserve-libs" should have caught this. Reassigning to the
> portage folks.

It doesn't because this version gets uninstalled, not replaced. Preserved libs
still need a package they belong to.

(In reply to comment #2)
> As the two libs are sloted, this should not have broken anything on your
> install, strange.
> 
> On my ~amd64 system, I did :
> emerge -Dvua world

If that finishes successfully, you shouldn't have more than one slot of libpng
installed.
Comment 5 Omar Saleem 2010-05-09 18:54:18 UTC
regardless of whether i did this in any wisdom or not, i manually slotted 1.2 and 1.4 (because i thought that's how it was supposed to be, since there were both :0 and :1.2 slots).
but as such it appears that whichever gets installed last and becomes the active install takes precedence...so for whatever reason libpng12 dissolves
Comment 6 Adrian Bassett 2010-05-09 18:57:01 UTC
his is a disaster.

Initially many apps were broken.  

Then, having tried various approaches including preserved-rebuild (initially
not an option), revdep-rebuild, and installing/re-installing both versions, the
situation began to look normal but in fact is only broken differently in that
apps are now linked against both(!) versions of libpng:

# ldd /usr/bin/rrdtool | grep png 
        libpng12.so.0 => /usr/lib/libpng12.so.0 (0x00007f9886f8c000)
        libpng14.so.14 => /usr/lib/libpng14.so.14 (0x00007f9886893000)

meaning that preserved-rebuild wants to go round the loop again:

[ebuild   R   ] net-analyzer/rrdtool-1.4.2  USE="lua perl python rrdcgi ruby
tcl -doc"

Only libpng-1.4.2 is actually installed (no slots).

Comment 7 Sebastian Luther (few) 2010-05-09 19:03:30 UTC
(In reply to comment #6)
> his is a disaster.
> 
> Initially many apps were broken.  
> 
> Then, having tried various approaches including preserved-rebuild (initially
> not an option), revdep-rebuild, and installing/re-installing both versions, the
> situation began to look normal but in fact is only broken differently in that
> apps are now linked against both(!) versions of libpng:
> 
> # ldd /usr/bin/rrdtool | grep png 
>         libpng12.so.0 => /usr/lib/libpng12.so.0 (0x00007f9886f8c000)
>         libpng14.so.14 => /usr/lib/libpng14.so.14 (0x00007f9886893000)
> 
> meaning that preserved-rebuild wants to go round the loop again:
> 
> [ebuild   R   ] net-analyzer/rrdtool-1.4.2  USE="lua perl python rrdcgi ruby
> tcl -doc"
> 
> Only libpng-1.4.2 is actually installed (no slots).
> 

How do you manage to have two libpng slots installed?
Comment 8 Omar Saleem 2010-05-09 19:07:43 UTC
i'm the one with two libpng slots installed
and i use paludis
so, 
$ paludis -i =media-libs/libpng-1.2.43.-r1:1.2 =media-libs/libpng-1.4.2:0
Comment 9 Sebastian Luther (few) 2010-05-09 19:27:17 UTC
(In reply to comment #8)
> i'm the one with two libpng slots installed
> and i use paludis
> so, 
> $ paludis -i =media-libs/libpng-1.2.43.-r1:1.2 =media-libs/libpng-1.4.2:0
> 

Yeah, you're right, I missed that 1.2.43-r1 is in slot 1.2.

@base-system: Is it intentional that these two version can be installed together?
In addition, you most likely want a strong block, because otherwise people using --jobs might have two (weak) blocking versions installed for some time.
Comment 10 Gef 2010-05-09 19:42:26 UTC
(In reply to comment #3)
> (In reply to comment #0)

I see your point about preserve-rebuild, however, doing a regular emerge -D -u world does actually :
- upgrade libpng from 1.2.43 to 1.2.43-r1 in slot :1.2
- and install 1.4.2 in slot :0

At least it is precisely what it did on my box.
Comment 11 Nikolaos Chatzidakis 2010-05-09 20:08:08 UTC
Ok, people, i finally solved it for me. I had to emerge kdelibs first to find the new libpng, and then i ran revdep-rebuild and everything compiles smoothly again... Try it too (if you have kde).
Comment 12 Harald van Dijk (RETIRED) gentoo-dev 2010-05-09 20:22:43 UTC
(In reply to comment #10)
> (In reply to comment #3)
> > (In reply to comment #0)
> 
> I see your point about preserve-rebuild, however, doing a regular emerge -D -u
> world does actually :
> - upgrade libpng from 1.2.43 to 1.2.43-r1 in slot :1.2
> - and install 1.4.2 in slot :0
> 
> At least it is precisely what it did on my box.

It may do that if you have any packages installed that pull in libpng 1.2. If you don't, it will install libpng 1.4.2, and then uninstall 1.2.43.

At least it is precisely what it did on my box. :)
Comment 13 Cyrill Helg 2010-05-09 20:59:35 UTC
Can you compile x11-misc/notification-daemon against new libpng?

I get this: 

/bin/sh ../../libtool --tag=CC --mode=link i686-pc-linux-gnu-gcc  -O2 -march=pentium-m -pipe -Wall  -Wl,-O1 -Wl,--sort-common -o notification-properties  notification-properties.o -lglade-2.0 -lxml2 -lgconf-2 -lnotify -lgtk-x11-2.0 -lgdk-x11-2.0 -latk-1.0 -lgio-2.0 -lpangoft2-1.0 -lgdk_pixbuf-2.0 -lpangocairo-1.0 -lcairo -lpango-1.0 -lfreetype -lfontconfig -lgmodule-2.0 -ldbus-glib-1 -ldbus-1 -lpthread -lrt -lgobject-2.0 -lglib-2.0   
libtool: link: i686-pc-linux-gnu-gcc -O2 -march=pentium-m -pipe -Wall -Wl,-O1 -Wl,--sort-common -o notification-properties notification-properties.o  /usr/lib/libglade-2.0.so -L/usr/lib -lpng12 /usr/lib/libxml2.so /usr/lib/libgconf-2.so /usr/lib/libORBit-2.so /usr/lib/libgthread-2.0.so /usr/lib/libnotify.so /usr/lib/libgtk-x11-2.0.so /usr/lib/libgdk-x11-2.0.so /usr/lib/libatk-1.0.so /usr/lib/libgdk_pixbuf-2.0.so /usr/lib/libgio-2.0.so -lresolv /usr/lib/libpangocairo-1.0.so /usr/lib/libpangoft2-1.0.so /usr/lib/libcairo.so /usr/lib/libpixman-1.so /usr/lib/libglitz-glx.so /usr/lib/libXmu.so /usr/lib/libXt.so /usr/lib/libSM.so -luuid /usr/lib/libICE.so /usr/lib/libXi.so /usr/lib/libXext.so -lGL /usr/lib/libglitz.so /usr/lib/libpng14.so /usr/lib/libxcb-render-util.so /usr/lib/libxcb-render.so /usr/lib/libXrender.so /usr/lib/libX11.so /usr/lib/libxcb.so /usr/lib/libXau.so /usr/lib/libXdmcp.so /usr/lib/libpango-1.0.so -lm /usr/lib/libfontconfig.so /usr/lib/libfreetype.so -lz /usr/lib/libexpat.so /usr/lib/libgmodule-2.0.so -ldl /usr/lib/libdbus-glib-1.so /usr/lib/libdbus-1.so -lpthread -lrt /usr/lib/libgobject-2.0.so /usr/lib/libglib-2.0.so -pthread
/usr/lib/gcc/i686-pc-linux-gnu/4.4.3/../../../../i686-pc-linux-gnu/bin/ld: cannot find -lpng12
collect2: ld returned 1 exit status
distcc[30451] ERROR: compile (null) on localhost failed
make[3]: *** [notification-properties] Error 1
make[2]: *** [all-recursive] Error 1
make[1]: *** [all-recursive] Error 1


I guess I should file a new bugreport?
Comment 14 Nikolaos Chatzidakis 2010-05-09 21:06:52 UTC
(In reply to comment #11)
> Ok, people, i finally solved it for me. I had to emerge kdelibs first to find
> the new libpng, and then i ran revdep-rebuild and everything compiles smoothly
> again... Try it too (if you have kde).
> 

Update: I had to emerge libglade again :) everything compiled fine. :)
Comment 15 Jonathan Adamczewski 2010-05-09 22:34:19 UTC
(In reply to comment #12)
> 
> It may do that if you have any packages installed that pull in libpng 1.2. If
> you don't, it will install libpng 1.4.2, and then uninstall 1.2.43.
> 
> At least it is precisely what it did on my box. :)
> 

That was my experience.
Comment 16 fkhp 2010-05-10 06:24:18 UTC
it broked the whole gnome desktop indeed. 

using emerge to do pakcage update it will upgrade libpng-1.2.43-r1/r2 to libpng-1.4.2, using paludis, libpng-1.2.43-r1 will take a new slot and installed side by side with 1.4.2,  libpng-1.2.43-r2 will take the same slot with  libpng-1.4.2 so that they replace each other when install one or the other. and "paludis -q libpng" shows this is the case.

maybe 1.4.2 should take a slot alone;  libpng-1.2.43-r1 and  libpng-1.2.43-r2 take the same :1.2 slot.
Comment 17 PM 2010-05-10 11:17:32 UTC
Here's what I did: first I removed all versions of libpng, then I installed 1.2.43-r2 from slot 0 and upgraded it to 1.4.2. That way portage caught the old lib and provided the preserved-rebuild set.

I also noticed, that 1.2.43-r1 form slot 1.2 doesn't install the /usr/lib64/libpng12.so.0 symlink - and apps are unable to find id until I make that link by hand.
Comment 18 blackdream 2010-05-10 12:35:28 UTC
(In reply to comment #17)
> Here's what I did: first I removed all versions of libpng, then I installed
> 1.2.43-r2 from slot 0 and upgraded it to 1.4.2. That way portage caught the old
> lib and provided the preserved-rebuild set.
> 
> I also noticed, that 1.2.43-r1 form slot 1.2 doesn't install the
> /usr/lib64/libpng12.so.0 symlink - and apps are unable to find id until I make
> that link by hand.
> 

how to make that link by hand????
Comment 19 PM 2010-05-10 12:38:25 UTC
@blackdream
cd /usr/lib
ln -s libpng12.so.0.43.0 libpng12.so.0
Comment 20 blackdream 2010-05-10 12:40:45 UTC
(In reply to comment #19)
> @blackdream
> cd /usr/lib
> ln -s libpng12.so.0.43.0 libpng12.so.0
> 

have U unmerge the libpng-1.2.43-r1????

the links is already exist................
Comment 21 Ferry 2010-05-10 12:52:04 UTC
How did you guys rebuild everything against the new libpng? Still kind of
stuck. Some packages seem to recompile, others do not. Still fighting with the
order (no revdep-rebuild does *NOT* get the order right).

I'm on ~amd64 (fully unstable). Perhaps some packages are still looking for the
old version (in fact, they try to link hard against the old version). Don't
know where they get the version number from. The old version is in /usr/lib32
but this probably comes with a binary compatibility package. I run very little
(if any) 32 bit software.

flaptoppy / # cd /usr/lib32
flaptoppy lib32 # ls -l libpng*
lrwxrwxrwx 1 root root     18 apr 15 21:50 libpng12.so -> libpng12.so.0.40.0
lrwxrwxrwx 1 root root     18 apr 15 21:50 libpng12.so.0 -> libpng12.so.0.40.0
-rwxr-xr-x 1 root root 140968 dec 30 15:27 libpng12.so.0.40.0
lrwxrwxrwx 1 root root     11 apr 15 21:50 libpng.so -> libpng12.so
lrwxrwxrwx 1 root root     16 apr 15 21:50 libpng.so.3 -> libpng.so.3.40.0
-rwxr-xr-x 1 root root 153708 dec 30 15:27 libpng.so.3.40.0
flaptoppy lib32 # cd ../lib
flaptoppy lib # ls -l libpng*
-rw-r--r-- 1 root root 236542 mei 10 09:48 libpng14.a
-rw-r--r-- 1 root root    935 mei 10 09:48 libpng14.la
lrwxrwxrwx 1 root root     18 mei 10 09:48 libpng14.so -> libpng14.so.14.2.0
lrwxrwxrwx 1 root root     18 mei 10 09:48 libpng14.so.14 -> libpng14.so.14.2.0
-rwxr-xr-x 1 root root 158400 mei 10 09:48 libpng14.so.14.2.0
lrwxrwxrwx 1 root root     10 mei 10 09:48 libpng.a -> libpng14.a
lrwxrwxrwx 1 root root     11 mei 10 09:48 libpng.la -> libpng14.la
lrwxrwxrwx 1 root root     11 mei 10 09:48 libpng.so -> libpng14.so

Still seeing how far I can get by putting the packages revdep-rebuild finds
manually in a 'emerge -j 3 --keep-going -1 <pacagkes>'. The list slowly gets
smaller, but although I think I have most base libs recompiled, there are still
quite a few packages failing.

Will see how far I can get. Eventually I should only have a list of packages
left that won't compile now, since due to deps some compile now after I had
some others.
Comment 22 Adrian Bassett 2010-05-10 18:58:38 UTC
(In reply to comment #17)
> Here's what I did: first I removed all versions of libpng, then I installed
> 1.2.43-r2 from slot 0 and upgraded it to 1.4.2. That way portage caught the old
> lib and provided the preserved-rebuild set.

This was very useful advice.  It worked perfectly on all my non-libpng-broken systems.

Thanks. 


Comment 23 Tom-Steve Watzke 2010-05-10 20:42:21 UTC
I got many ld errors ... cannot find -lpng12 ...
(I have both versions installed)
Then I tried the following, since it needs the old one:
cd /usr/lib
ln -snvf libpng12.so.0.43.0 libpng12.so
cd /usr/lib64
ln -snvf libpng12.so.0.43.0 libpng12.so

THAT WORKED :D
That means ld will find it for now, e.g.:
ld -l png12
will give other output than "not found".
Comment 24 Ferry 2010-05-10 21:18:43 UTC
Been recompiling for a while, only had the new version installed. Even after unmerging all libpng versions, remerging 1.2.43-r2 and then upgrading it didn't get slotted. @preserved-rebuild doesn't have it either.

These are the 18 packages I can't get past:

dev-python/gnome-applets-python
dev-python/gtkhtml-python
dev-python/libbonobo-python
dev-python/libgnomecanvas-python
dev-python/libgnome-python
gnome-base/gdm
gnome-base/gnome-applets
gnome-base/gnome-panel
gnome-base/libbonoboui
gnome-base/libgnomeprintui
gnome-base/libgnomeui
gnome-extra/gnome-power-manager
gnome-extra/gnome-system-monitor
gnome-extra/gnome-utils
mail-client/evolution
media-sound/grip
net-analyzer/gnome-netstatus
net-print/gnome-cups-manager

For now I just emerged the older version, grabbed some files, upgraded, copied the files in and I have a working system now. Will have to remember to remove them eventually.

Copied these back:

-rw-r--r-- 1 root root 241214 mei 10 22:54 /usr/lib64/libpng12.a
-rw-r--r-- 1 root root    934 mei 10 22:54 /usr/lib64/libpng12.la
lrwxrwxrwx 1 root root     18 mei 10 22:57 /usr/lib64/libpng12.so -> libpng12.so.0.43.0
lrwxrwxrwx 1 root root     18 mei 10 22:57 /usr/lib64/libpng12.so.0 -> libpng12.so.0.43.0
-rwxr-xr-x 1 root root 158520 mei 10 22:54 /usr/lib64/libpng12.so.0.43.0
Comment 25 Ferry 2010-05-10 21:20:47 UTC
Btw, I also have kde4 installed, that recompiled fine. IIRC most of the order issues came from gnome and gnome packages seem to be much more dependent on it. Guessing in KDE it might be wrapped through kdelibs or something.
Comment 26 Marco Napetti 2010-05-10 21:54:46 UTC
I have the same problems, for now my solution has been masking =media-libs/libpng-1.4.2

The only packages that on my system can't rebuild against libpng new version were =dev-python/pygtk-2.16.0-r1 and =app-emulation/virtualbox-ose-3.1.6
Comment 27 georgi 2010-05-10 22:57:03 UTC
(In reply to comment #24)
> Been recompiling for a while, only had the new version installed. Even after
> unmerging all libpng versions, remerging 1.2.43-r2 and then upgrading it didn't
> get slotted. @preserved-rebuild doesn't have it either.

Try this:

emerge -1 libglade pango cairo glitz libgnomecanvas fontconfig freetype

I have no idea which ones are actually needed, but I managed to rebuild most of the Gnome stuff I have afterwards. If anything breaks, try a different order.

In fact, the only thing I still can't get to link is dev-python/gtksourceview-python:

ibtool: link:  x86_64-pc-linux-gnu-gcc -shared  .libs/gtksourceviewmodule.o .libs/gtksourceview.o   /usr/lib64/libgtksourceview-1.0.so -L/usr/lib64 /usr/lib64/libXmu.so /usr/lib64/libXt.so /usr/lib64/libSM.so -luuid /usr/lib64/libICE.so /usr/lib64/libXi.so /usr/lib64/libXext.so -lpng12 /usr/lib64/libgtk-x11-2.0.so /usr/lib64/libgnomeprint-2-2.so /usr/lib64/libgdk-x11-2.0.so /usr/lib64/libatk-1.0.so /usr/lib64/libgdk_pixbuf-2.0.so /usr/lib64/libgio-2.0.so -lresolv /usr/lib64/libpangocairo-1.0.so /usr/lib64/libpangoft2-1.0.so /usr/lib64/libcairo.so /usr/lib64/libpixman-1.so /usr/lib64/libglitz-glx.so -lGL -lpthread /usr/lib64/libglitz.so /usr/lib64/libpng14.so /usr/lib64/libxcb-render-util.so /usr/lib64/libxcb-render.so /usr/lib64/libXrender.so /usr/lib64/libX11.so /usr/lib64/libxcb.so /usr/lib64/libXau.so /usr/lib64/libXdmcp.so /usr/lib64/libfontconfig.so /usr/lib64/libfreetype.so /usr/lib64/libexpat.so /usr/lib64/libart_lgpl_2.so /usr/lib64/libxml2.so -lz /usr/lib64/libpango-1.0.so -lm /usr/lib64/libgobject-2.0.so /usr/lib64/libgmodule-2.0.so -ldl /usr/lib64/libglib-2.0.so  -march=core2 -Wl,-O1   -Wl,-soname -Wl,gtksourceview.so -Wl,-version-script -Wl,.libs/gtksourceview.ver -o .libs/gtksourceview.so
/usr/lib/gcc/x86_64-pc-linux-gnu/4.4.3/../../../../x86_64-pc-linux-gnu/bin/ld: cannot find -lpng12
collect2: ld returned 1 exit status
Comment 28 Omar Saleem 2010-05-11 01:26:54 UTC
(In reply to comment #19)
> @blackdream
> cd /usr/lib
> ln -s libpng12.so.0.43.0 libpng12.so.0
> 

i don't seem to have libpng12.so.0.43.0, and i followed the instructions in comment #17, but everything is still broken
keeping 1.2.43-r2 installed has been my fix, most packages are okay with that, though my custom install of mplayer isn't...
Comment 29 Tom-Steve Watzke 2010-05-11 05:24:49 UTC
I already posted the temporary solution for the linking-problem:
../i686-pc-linux-gnu/bin/ld: cannot find -lpng12
- needed of course is the old media-libs/libpng-1.2.43-r1
- that fixed my whole broken system

(In reply to comment #23)
> cd /usr/lib
> ln -snvf libpng12.so.0.43.0 libpng12.so
> cd /usr/lib64
> ln -snvf libpng12.so.0.43.0 libpng12.so
Comment 30 Gef 2010-05-11 07:18:16 UTC
Actually, there are very few packages that don't compile with libpng-1.4, and most of them have already received a patch in the tree.

To recompile everything against the new libpng:
If temporary breakage is not a problem for you:
1) lafilefixer --justfixit
2) emerge -av1 =libpng-1.4.2
3) emerge -avC libpng:0
4) revdep-rebuild -- -av1 --keep-going
5) Now, some package will fail to recompile (thus --keep-going), because they use link-time flags from .la files of libraries belonging to some of their dependencies. To find the "faulty" packages, use something like:

for item in $(ls -1R *.la); do if $(grep -q png12 $item); then qfile $item; fi; done

and then recompile the package in the list from the output of above script.
6) Another run of revdep-rebuild, and your system should be clean (excepted packages that really fail with the new libpng. If you still require them, install the old libpng:0 and create the needed symlink in /usr/lib/)

Anyway, this is ~arch, always fun.
YMMV
Comment 31 fkhp 2010-05-11 07:50:30 UTC
 this solution to put libpng-1.2.43-r2 in slot :1.2 :

# cd /usr/portage/media-libs/libpng
# sed -i 's/SLOT="0"/SLOT="1.2"/' libpng-1.2.43-r2.ebuild
# ebuild libpng-1.2.43-r2.ebuild manifest
# paludis -i1 =media-libs/libpng-1.2.43-r2
# paludis -i1 libpng

then nothing will be broken, and no fixing needed any more.
Comment 32 Samuli Suominen gentoo-dev 2010-05-11 08:01:40 UTC
(In reply to comment #31)
>  this solution to put libpng-1.2.43-r2 in slot :1.2 :
> 
> # cd /usr/portage/media-libs/libpng
> # sed -i 's/SLOT="0"/SLOT="1.2"/' libpng-1.2.43-r2.ebuild
> # ebuild libpng-1.2.43-r2.ebuild manifest
> # paludis -i1 =media-libs/libpng-1.2.43-r2
> # paludis -i1 libpng
> 
> then nothing will be broken, and no fixing needed any more.
> 

that's wrong in so many ways, just let's hope nobody will take your advise :)
Comment 33 Samuli Suominen gentoo-dev 2010-05-11 08:13:48 UTC
My steps:

1. Upgrade to libpng-1.4.2
2. revdep-rebuild (or @preserved-rebuild)

[ until one of them bails out at some point ]

3. Run something like "libpng-1.4.x-update.sh", a.k.a. fix broken .la files
4. Finish my revdep-rebuild (or @preserved-rebuild)

Worked like a breeze. I can imagine also few --resume --skip-first or --keep-going's saving the day.

At any rate it's just a bit more difficult upgrade than everyday jpeg or expat upgrade (just kidding). I don't think there's anything special required to do here.
Comment 34 Matthias Fulz 2010-05-11 09:57:59 UTC
(In reply to comment #33)
> My steps:
> 
> 1. Upgrade to libpng-1.4.2
> 2. revdep-rebuild (or @preserved-rebuild)
> 
> [ until one of them bails out at some point ]
> 
> 3. Run something like "libpng-1.4.x-update.sh", a.k.a. fix broken .la files
> 4. Finish my revdep-rebuild (or @preserved-rebuild)

Do you mean lafilefixer --justfixit ?

> 
> Worked like a breeze. I can imagine also few --resume --skip-first or
> --keep-going's saving the day.
> 

Not for me many packaged still searching libpng12.la and stop emerging


Comment 35 Helmut Eberharter 2010-05-11 12:17:29 UTC
(In reply to comment #34)
> Not for me many packaged still searching libpng12.la and stop emerging

After struggling with different approaches of install/uninstall, revdep-rebuild, lafilefixer, libpng-1.4.x-update.sh this worked:

* Uninstall all libpng versions
* Install libpng-1.4.2
* Unmask & Install libpng-1.2.43-r1 (because I still got packages depending on <1.4)
* revdep-rebuild (didn't find any thing here, but i ran it multiple times before)



Comment 36 Sven Müller 2010-05-11 12:27:47 UTC
(In reply to comment #35)
> * Unmask & Install libpng-1.2.43-r1 (because I still got packages depending on
> <1.4)

It's slotted in my case. I don't have to unmask anything. 

eix libpng
[I] media-libs/libpng
     Available versions:
        (1.2)   *1.2.40 1.2.43-r1
        (0)     1.2.43-r2 (~)1.4.2
     Installed versions:  1.2.43-r1(1.2)(21:00:49 10.05.2010) 1.4.2(10:30:58 11.05.2010)

Nevertheless I'm recompiling half of the system due to this - including gcc. So I have to wait a couple of hours.
Comment 37 Ferry 2010-05-11 12:43:15 UTC
Hi,

remerging, no matter what the order did not solve it for me.

Note, portage does *NOT* slot here, I *only* have 1.4. There are also *NO* 1.2 files left behind (for people noticing I copied them from old install, I removed them again), as is the case with some others apparently (some people here only recreate 2 symlinks and have no issues then, the file (libpng12.so.0.43.0) the symlink points to is gone here as well). 

As you can see from my previous posts, rerunning emerge lots of times (over 20...) got it reduced to 18 packages.

Then I saw mention of the /usr/portage/media-libs/libpng/files/libpng-1.4.x-update.sh script. Read it and saw it fixes la files.

Recalled having issues with la files before and figured I'd just run 'lafilefixer --justfixit' and get it sorted out. Unfortunately, this doesn't work. Apparently lafilefixer only fixes a subnet (it did update over 90% of the libraries.... iek...). Don't quite get la files pointing to hard filenames in the first place and they apparently get updated badly. Anyways, after lafilefixer tried to emerge the 18 packages again, I run it with -j 3, first 3 it tried failed.

Aborted emerge, ran the provided script (/usr/portage/media-libs/libpng/files/libpng-1.4.x-update.sh), emerges fine now (12 of 18 done, not done yet, but no errors so far).

One does wonder why lafilefixer didn't get it. Apparently it doesn't fix everything.
Comment 38 Ferry 2010-05-11 12:45:08 UTC
Err gcc definitely doesn't depend on libpng... I presume you choose to do this?
Comment 39 Arfrever Frehtes Taifersar Arahesis (RETIRED) gentoo-dev 2010-05-11 12:50:16 UTC
Everybody except Portage developers:
Please stop commenting on this bug and use e.g. Gentoo Forums.
Comment 40 Matthias Fulz 2010-05-11 13:09:43 UTC
(In reply to comment #37)
> Hi,
> 
> remerging, no matter what the order did not solve it for me.
> 
> Note, portage does *NOT* slot here, I *only* have 1.4. There are also *NO* 1.2
> files left behind (for people noticing I copied them from old install, I
> removed them again), as is the case with some others apparently (some people
> here only recreate 2 symlinks and have no issues then, the file
> (libpng12.so.0.43.0) the symlink points to is gone here as well). 
> 
> As you can see from my previous posts, rerunning emerge lots of times (over
> 20...) got it reduced to 18 packages.
> 
> Then I saw mention of the
> /usr/portage/media-libs/libpng/files/libpng-1.4.x-update.sh script. Read it and
> saw it fixes la files.
> 
> Recalled having issues with la files before and figured I'd just run
> 'lafilefixer --justfixit' and get it sorted out. Unfortunately, this doesn't
> work. Apparently lafilefixer only fixes a subnet (it did update over 90% of the
> libraries.... iek...). Don't quite get la files pointing to hard filenames in
> the first place and they apparently get updated badly. Anyways, after
> lafilefixer tried to emerge the 18 packages again, I run it with -j 3, first 3
> it tried failed.
> 
> Aborted emerge, ran the provided script
> (/usr/portage/media-libs/libpng/files/libpng-1.4.x-update.sh), emerges fine now
> (12 of 18 done, not done yet, but no errors so far).
> 
> One does wonder why lafilefixer didn't get it. Apparently it doesn't fix
> everything.
> 

All not working for me.

I need to mask libpng-1.4.2 to receive a running system.
Comment 41 Navid Zamani 2010-05-11 13:31:38 UTC
This problem caused **massive** headaches here.

My desktop did not work until I rebuild over 100 packages. And then it worked only halfways, because I have 135 packages that do still expect libpng.1.2x when trying to rebuild them with revdep-rebuild. (Which fails)
Only masking >=media-libs/libpng-1.3 did help. (At which point I did not need to rebuild them.)

It took me from Sunday till now, and I still ain’t back to a working system. (Still revdep-rebuilding the already rebuilt packages back to 1.2.x after masking.)

I know that one shouldn’t complain when one gets something for free, but who thought this was a good idea? :/
These problems are the reason you can’t put Gentoo on servers that have to work all the time... :/
Comment 42 Matthias Fulz 2010-05-11 13:38:24 UTC
(In reply to comment #41)
> This problem caused **massive** headaches here.
> 
> My desktop did not work until I rebuild over 100 packages. And then it worked
> only halfways, because I have 135 packages that do still expect libpng.1.2x
> when trying to rebuild them with revdep-rebuild. (Which fails)
> Only masking >=media-libs/libpng-1.3 did help. (At which point I did not need
> to rebuild them.)
> 
> It took me from Sunday till now, and I still ain’t back to a working system.
> (Still revdep-rebuilding the already rebuilt packages back to 1.2.x after
> masking.)
> 
> I know that one shouldn’t complain when one gets something for free, but who
> thought this was a good idea? :/
> These problems are the reason you can’t put Gentoo on servers that have to
> work all the time... :/
> 

Offtopic:

Hey dude libpng-1.4.2 is ~amd64 ~x86, etc

I think the reason why you use it is you WANT TO TEST for others, because you are an experienced user?

I really can only hope that you don't use unstable versions of ANY distribution on critical servers?!

P.S.: libpng-1.2.43-r2 is working on my host perfectly (ok needed to rebuild many packages, but that's something I know, instead I wouldn't use Gentoo if I don't want to compile).
Comment 43 Navid Zamani 2010-05-11 14:26:45 UTC
<offtopic> (Feel free to ignore. That would only strengthen my argument. ;)
(In reply to comment #42)
> Hey dude libpng-1.4.2 is ~amd64 ~x86, etc
First of all, I’m not your dude. :)
> I think the reason why you use it is you WANT TO TEST for others, because you
> are an experienced user?
Second: Agreed. :) Sorry, this is true in this case. I should have specified that I did mean this in general, for stable packages too.
> I really can only hope that you don't use unstable versions of ANY distribution
> on critical servers?!
No, I’m not insane. :) I would be as shocked as you. Unfortunately I tried stable, even hardened x86 on a dedicated testing server, to look it it would be an option to switch critical servers to it. After huge problems I switched it back to Debian. (And, yes, I am a very experienced user. I am usually the one giving support, not receiving it. :)

> P.S.: libpng-1.2.43-r2 is working on my host perfectly (ok needed to rebuild
> many packages, but that's something I know, instead I wouldn't use Gentoo if I
> don't want to compile).
Straw man argument. Nobody said I would not want to compile or that 1.2.x would not work. Even 1.4.x does work. The problem is that lots of packages still expect 1.2.x when only 1.4.x is installed, as their ebuild dependencies are apparently faulty.
I’d bet you money that you will fall over that one when 1.4.x is going stable, as I know how such incidents were handled in the past, and that in that regard, policies and mechanics haven’t changed.
</offtopic>

Comment 44 Peter Ruskin 2010-05-11 16:22:58 UTC
I had to add media-libs/libpng-1.4.2 to my overlay and change slot from 0 to 1.4 and mask 1.2.43-r2.  Then 1.2.43 and 1.4.2 can co-exist happily.
Comment 45 Samuli Suominen gentoo-dev 2010-05-11 16:38:13 UTC
(In reply to comment #44)
> I had to add media-libs/libpng-1.4.2 to my overlay and change slot from 0 to
> 1.4 and mask 1.2.43-r2.  Then 1.2.43 and 1.4.2 can co-exist happily.
> 

Nobody needs to repeat your mistake, they can be installed slotted from Portage fine as-is,

$ sudo emerge -pv =libpng-1.2.43-r1 =libpng-1.4.2

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

Calculating dependencies... done!
[ebuild  NS   ] media-libs/libpng-1.2.43-r1 [1.4.2] 0 kB
[ebuild   R   ] media-libs/libpng-1.4.2  0 kB

Total: 2 packages (1 in new slot, 1 reinstall), Size of downloads: 0 kB
Comment 46 PM 2010-05-11 18:07:19 UTC
I'll repeat for all those who ended up with a broken system (binaries linked against old libpng not working):

1)# emerge -C libpng
2)# emerge -1 =media-libs/libpng-1.2.43-r2
3)# emerge -1 libpng

That way portage will keep the old libpng.12.so until all packages linking against it are rebuilt.
Comment 47 Omar Saleem 2010-05-11 18:41:48 UTC
i have libpng-1.2.43-r2 installed, no other versions of libpng
but i don't have libpng12.so or in fact ANYTHING with libpng12.so in the filename in /lib or /usr/lib
however, all of my packages work. so i don't really understand what's going on but trying to update to libpng-1.4.2 breaks everything.
Comment 48 fkhp 2010-05-12 03:54:47 UTC
with 1.4.2 installed only without 1.2: and after revdep-rebuild, /usr/sbin/libpng-1.4.x-update.sh, revdep-rebuild, 

gnome-panel 2.28/2.30(both) crashed immediately after desktop startup, showing a bug budy message:
==========================
Distribution: Gentoo Base System release 2.0.1
Gnome Release: 2.30.0 2010-05-11 (Gentoo)
BugBuddy Version: 2.30.0

System: Linux 2.6.33-ccs-r2 #1 SMP Tue May 4 01:58:19 CST 2010 x86_64
X Vendor: The X.Org Foundation
X Vendor Release: 10800000
Selinux: No
Accessibility: Enabled
GTK+ Theme: Clearlooks
Icon Theme: gnome
GTK+ Modules: canberra-gtk-module, gnomebreakpad, gail:atk-bridge

Memory status: size: 475983872 vsize: 475983872 resident: 22700032 share: 17338368 rss: 22700032 rss_rlim: 18446744073709551615
CPU usage: start_time: 1273635414 rtime: 33 utime: 30 stime: 3 cutime:0 cstime: 0 timeout: 0 it_real_value: 0 frequency: 100

Backtrace was generated from '/usr/bin/gnome-panel'

Traceback (most recent call last):
  File "/usr/share/gdb/auto-load/usr/lib64/libgobject-2.0.so.0.2400.1-gdb.py", line 9, in <module>
    from gobject import register
  File "/usr/share/glib-2.0/gdb/gobject.py", line 3, in <module>
    import gdb.backtrace
ImportError: No module named backtrace
[Thread debugging using libthread_db enabled]
Traceback (most recent call last):
  File "/usr/share/gdb/auto-load/usr/lib64/gcc/x86_64-pc-linux-gnu/4.5.0/libstdc++.so.6.0.14-gdb.py", line 59, in <module>
    from libstdcxx.v6.printers import register_libstdcxx_printers
ImportError: No module named libstdcxx.v6.printers
0x00007febbb5945fe in waitpid () from /lib/libpthread.so.0
#0  0x00007febbb5945fe in waitpid () from /lib/libpthread.so.0
#1  0x00007febbb0fdc21 in g_spawn_sync () from /usr/lib/libglib-2.0.so.0
#2  0x00007febbb0fe1a1 in g_spawn_command_line_sync ()
   from /usr/lib/libglib-2.0.so.0
#3  0x00007febb8600e38 in bugbuddy_segv_handle(int) ()
   from /usr/lib64/gtk-2.0/modules/libgnomebreakpad.so
#4  <signal handler called>
#5  0x00007febba1b8bd5 in raise () from /lib/libc.so.6
#6  0x00007febba1ba415 in abort () from /lib/libc.so.6
#7  0x00007febbb0c05de in g_logv () from /usr/lib/libglib-2.0.so.0
#8  0x00007febbb0c0673 in g_log () from /usr/lib/libglib-2.0.so.0
#9  0x00007febbb0be4dc in g_malloc () from /usr/lib/libglib-2.0.so.0
#10 0x00007febbb08ff9d in g_base64_encode () from /usr/lib/libglib-2.0.so.0
#11 0x00007febad10f557 in ?? ()
   from /usr/lib64/gtk-2.0/2.10.0/loaders/libpixbufloader-png.so
#12 0x00007febbd21b807 in png_push_read_chunk () from /usr/lib/libpng14.so.14
#13 0x00007febbd21c84b in png_process_data () from /usr/lib/libpng14.so.14
#14 0x00007febad10eb12 in ?? ()
   from /usr/lib64/gtk-2.0/2.10.0/loaders/libpixbufloader-png.so
#15 0x00007febbe23394a in gdk_pixbuf_loader_write ()
   from /usr/lib/libgdk_pixbuf-2.0.so.0
#16 0x00007febbe231406 in gdk_pixbuf_new_from_file_at_scale ()
   from /usr/lib/libgdk_pixbuf-2.0.so.0
#17 0x000000000043a005 in panel_load_icon ()
#18 0x000000000042e620 in button_widget_reload_pixbuf ()
#19 0x000000000042f1a6 in button_widget_size_allocate ()
#20 0x00007febbbbb8397 in g_closure_invoke () from /usr/lib/libgobject-2.0.so.0
#21 0x00007febbbbc6e78 in signal_emit_unlocked_R ()
   from /usr/lib/libgobject-2.0.so.0
#22 0x00007febbbbd16ab in g_signal_emit_valist ()
   from /usr/lib/libgobject-2.0.so.0
#23 0x00007febbbbd1863 in g_signal_emit () from /usr/lib/libgobject-2.0.so.0
#24 0x00007febbeb72a21 in gtk_widget_size_allocate ()
   from /usr/lib/libgtk-x11-2.0.so.0
#25 0x000000000042adaf in panel_widget_size_allocate ()
#26 0x00007febbbbb8397 in g_closure_invoke () from /usr/lib/libgobject-2.0.so.0
#27 0x00007febbbbc6e78 in signal_emit_unlocked_R ()
   from /usr/lib/libgobject-2.0.so.0
#28 0x00007febbbbd16ab in g_signal_emit_valist ()
   from /usr/lib/libgobject-2.0.so.0
#29 0x00007febbbbd1863 in g_signal_emit () from /usr/lib/libgobject-2.0.so.0
#30 0x00007febbeb72a21 in gtk_widget_size_allocate ()
   from /usr/lib/libgtk-x11-2.0.so.0
#31 0x000000000046041a in panel_frame_size_allocate ()
#32 0x00007febbbbb8397 in g_closure_invoke () from /usr/lib/libgobject-2.0.so.0
#33 0x00007febbbbc6e78 in signal_emit_unlocked_R ()
   from /usr/lib/libgobject-2.0.so.0
#34 0x00007febbbbd16ab in g_signal_emit_valist ()
   from /usr/lib/libgobject-2.0.so.0
#35 0x00007febbbbd1863 in g_signal_emit () from /usr/lib/libgobject-2.0.so.0
#36 0x00007febbeb72a21 in gtk_widget_size_allocate ()
   from /usr/lib/libgtk-x11-2.0.so.0
#37 0x00007febbeadc9a4 in ?? () from /usr/lib/libgtk-x11-2.0.so.0
#38 0x00007febbbbb8397 in g_closure_invoke () from /usr/lib/libgobject-2.0.so.0
#39 0x00007febbbbc6e78 in signal_emit_unlocked_R ()
   from /usr/lib/libgobject-2.0.so.0
#40 0x00007febbbbd16ab in g_signal_emit_valist ()
   from /usr/lib/libgobject-2.0.so.0
#41 0x00007febbbbd1863 in g_signal_emit () from /usr/lib/libgobject-2.0.so.0
#42 0x00007febbeb72a21 in gtk_widget_size_allocate ()
   from /usr/lib/libgtk-x11-2.0.so.0
#43 0x00000000004567f1 in panel_toplevel_size_allocate ()
#44 0x00007febbbbb8446 in g_closure_invoke () from /usr/lib/libgobject-2.0.so.0
#45 0x00007febbbbc6e78 in signal_emit_unlocked_R ()
   from /usr/lib/libgobject-2.0.so.0
#46 0x00007febbbbd16ab in g_signal_emit_valist ()
   from /usr/lib/libgobject-2.0.so.0
#47 0x00007febbbbd1863 in g_signal_emit () from /usr/lib/libgobject-2.0.so.0
#48 0x00007febbeb72a21 in gtk_widget_size_allocate ()
   from /usr/lib/libgtk-x11-2.0.so.0
#49 0x000000000045605b in panel_toplevel_check_resize ()
#50 0x00007febbbbb8446 in g_closure_invoke () from /usr/lib/libgobject-2.0.so.0
#51 0x00007febbbbc759c in signal_emit_unlocked_R ()
   from /usr/lib/libgobject-2.0.so.0
#52 0x00007febbbbd16ab in g_signal_emit_valist ()
   from /usr/lib/libgobject-2.0.so.0
#53 0x00007febbbbd1863 in g_signal_emit () from /usr/lib/libgobject-2.0.so.0
#54 0x00007febbe9d6700 in ?? () from /usr/lib/libgtk-x11-2.0.so.0
#55 0x00007febbe688316 in ?? () from /usr/lib/libgdk-x11-2.0.so.0
#56 0x00007febbb0b701e in g_main_context_dispatch ()
   from /usr/lib/libglib-2.0.so.0
#57 0x00007febbb0b78d0 in g_main_context_iterate ()
   from /usr/lib/libglib-2.0.so.0
#58 0x00007febbb0b8092 in g_main_loop_run () from /usr/lib/libglib-2.0.so.0
#59 0x00007febbea51ef7 in gtk_main () from /usr/lib/libgtk-x11-2.0.so.0
#60 0x000000000042888c in main ()

Thread 1 (Thread 0x7febc53228a0 (LWP 8074)):
#0  0x00007febbb5945fe in waitpid () from /lib/libpthread.so.0
No symbol table info available.
#1  0x00007febbb0fdc21 in g_spawn_sync () from /usr/lib/libglib-2.0.so.0
No symbol table info available.
#2  0x00007febbb0fe1a1 in g_spawn_command_line_sync ()
   from /usr/lib/libglib-2.0.so.0
No symbol table info available.
#3  0x00007febb8600e38 in bugbuddy_segv_handle(int) ()
   from /usr/lib64/gtk-2.0/modules/libgnomebreakpad.so
No symbol table info available.
#4  <signal handler called>
No symbol table info available.
#5  0x00007febba1b8bd5 in raise () from /lib/libc.so.6
No symbol table info available.
#6  0x00007febba1ba415 in abort () from /lib/libc.so.6
No symbol table info available.
#7  0x00007febbb0c05de in g_logv () from /usr/lib/libglib-2.0.so.0
No symbol table info available.
#8  0x00007febbb0c0673 in g_log () from /usr/lib/libglib-2.0.so.0
No symbol table info available.
#9  0x00007febbb0be4dc in g_malloc () from /usr/lib/libglib-2.0.so.0
No symbol table info available.
#10 0x00007febbb08ff9d in g_base64_encode () from /usr/lib/libglib-2.0.so.0
No symbol table info available.
#11 0x00007febad10f557 in ?? ()
   from /usr/lib64/gtk-2.0/2.10.0/loaders/libpixbufloader-png.so
No symbol table info available.
#12 0x00007febbd21b807 in png_push_read_chunk () from /usr/lib/libpng14.so.14
No symbol table info available.
#13 0x00007febbd21c84b in png_process_data () from /usr/lib/libpng14.so.14
No symbol table info available.
#14 0x00007febad10eb12 in ?? ()
   from /usr/lib64/gtk-2.0/2.10.0/loaders/libpixbufloader-png.so
No symbol table info available.
#15 0x00007febbe23394a in gdk_pixbuf_loader_write ()
   from /usr/lib/libgdk_pixbuf-2.0.so.0
No symbol table info available.
#16 0x00007febbe231406 in gdk_pixbuf_new_from_file_at_scale ()
   from /usr/lib/libgdk_pixbuf-2.0.so.0
No symbol table info available.
#17 0x000000000043a005 in panel_load_icon ()
No symbol table info available.
#18 0x000000000042e620 in button_widget_reload_pixbuf ()
No symbol table info available.
#19 0x000000000042f1a6 in button_widget_size_allocate ()
No symbol table info available.
#20 0x00007febbbbb8397 in g_closure_invoke () from /usr/lib/libgobject-2.0.so.0
No symbol table info available.
#21 0x00007febbbbc6e78 in signal_emit_unlocked_R ()
   from /usr/lib/libgobject-2.0.so.0
No symbol table info available.
#22 0x00007febbbbd16ab in g_signal_emit_valist ()
   from /usr/lib/libgobject-2.0.so.0
No symbol table info available.
#23 0x00007febbbbd1863 in g_signal_emit () from /usr/lib/libgobject-2.0.so.0
No symbol table info available.
#24 0x00007febbeb72a21 in gtk_widget_size_allocate ()
   from /usr/lib/libgtk-x11-2.0.so.0
No symbol table info available.
#25 0x000000000042adaf in panel_widget_size_allocate ()
No symbol table info available.
#26 0x00007febbbbb8397 in g_closure_invoke () from /usr/lib/libgobject-2.0.so.0
No symbol table info available.
#27 0x00007febbbbc6e78 in signal_emit_unlocked_R ()
   from /usr/lib/libgobject-2.0.so.0
No symbol table info available.
#28 0x00007febbbbd16ab in g_signal_emit_valist ()
   from /usr/lib/libgobject-2.0.so.0
No symbol table info available.
#29 0x00007febbbbd1863 in g_signal_emit () from /usr/lib/libgobject-2.0.so.0
No symbol table info available.
#30 0x00007febbeb72a21 in gtk_widget_size_allocate ()
   from /usr/lib/libgtk-x11-2.0.so.0
No symbol table info available.
#31 0x000000000046041a in panel_frame_size_allocate ()
No symbol table info available.
#32 0x00007febbbbb8397 in g_closure_invoke () from /usr/lib/libgobject-2.0.so.0
No symbol table info available.
#33 0x00007febbbbc6e78 in signal_emit_unlocked_R ()
   from /usr/lib/libgobject-2.0.so.0
No symbol table info available.
#34 0x00007febbbbd16ab in g_signal_emit_valist ()
   from /usr/lib/libgobject-2.0.so.0
No symbol table info available.
#35 0x00007febbbbd1863 in g_signal_emit () from /usr/lib/libgobject-2.0.so.0
No symbol table info available.
#36 0x00007febbeb72a21 in gtk_widget_size_allocate ()
   from /usr/lib/libgtk-x11-2.0.so.0
No symbol table info available.
#37 0x00007febbeadc9a4 in ?? () from /usr/lib/libgtk-x11-2.0.so.0
No symbol table info available.
#38 0x00007febbbbb8397 in g_closure_invoke () from /usr/lib/libgobject-2.0.so.0
No symbol table info available.
#39 0x00007febbbbc6e78 in signal_emit_unlocked_R ()
   from /usr/lib/libgobject-2.0.so.0
No symbol table info available.
#40 0x00007febbbbd16ab in g_signal_emit_valist ()
   from /usr/lib/libgobject-2.0.so.0
No symbol table info available.
#41 0x00007febbbbd1863 in g_signal_emit () from /usr/lib/libgobject-2.0.so.0
No symbol table info available.
#42 0x00007febbeb72a21 in gtk_widget_size_allocate ()
   from /usr/lib/libgtk-x11-2.0.so.0
No symbol table info available.
#43 0x00000000004567f1 in panel_toplevel_size_allocate ()
No symbol table info available.
#44 0x00007febbbbb8446 in g_closure_invoke () from /usr/lib/libgobject-2.0.so.0
No symbol table info available.
#45 0x00007febbbbc6e78 in signal_emit_unlocked_R ()
   from /usr/lib/libgobject-2.0.so.0
No symbol table info available.
#46 0x00007febbbbd16ab in g_signal_emit_valist ()
   from /usr/lib/libgobject-2.0.so.0
No symbol table info available.
#47 0x00007febbbbd1863 in g_signal_emit () from /usr/lib/libgobject-2.0.so.0
No symbol table info available.
#48 0x00007febbeb72a21 in gtk_widget_size_allocate ()
   from /usr/lib/libgtk-x11-2.0.so.0
No symbol table info available.
#49 0x000000000045605b in panel_toplevel_check_resize ()
No symbol table info available.
#50 0x00007febbbbb8446 in g_closure_invoke () from /usr/lib/libgobject-2.0.so.0
No symbol table info available.
#51 0x00007febbbbc759c in signal_emit_unlocked_R ()
   from /usr/lib/libgobject-2.0.so.0
No symbol table info available.
#52 0x00007febbbbd16ab in g_signal_emit_valist ()
   from /usr/lib/libgobject-2.0.so.0
No symbol table info available.
#53 0x00007febbbbd1863 in g_signal_emit () from /usr/lib/libgobject-2.0.so.0
No symbol table info available.
#54 0x00007febbe9d6700 in ?? () from /usr/lib/libgtk-x11-2.0.so.0
No symbol table info available.
#55 0x00007febbe688316 in ?? () from /usr/lib/libgdk-x11-2.0.so.0
No symbol table info available.
#56 0x00007febbb0b701e in g_main_context_dispatch ()
   from /usr/lib/libglib-2.0.so.0
No symbol table info available.
#57 0x00007febbb0b78d0 in g_main_context_iterate ()
   from /usr/lib/libglib-2.0.so.0
No symbol table info available.
#58 0x00007febbb0b8092 in g_main_loop_run () from /usr/lib/libglib-2.0.so.0
No symbol table info available.
#59 0x00007febbea51ef7 in gtk_main () from /usr/lib/libgtk-x11-2.0.so.0
No symbol table info available.
#60 0x000000000042888c in main ()
No symbol table info available.
A debugging session is active.

	Inferior 1 [process 8074] will be detached.

Quit anyway? (y or n) [answered Y; input not from terminal]


---- Critical and fatal warnings logged during execution ----

** GLib **: gmem.c:137: failed to allocate 187644257854905 bytes 


----------- .xsession-errors (485198 sec old) ---------------------
This probably reflects a bug in the program.
The error was 'BadMatch (invalid parameter attributes)'.
  (Details: serial 925 error_code 8 request_code 3 minor_code 0)
  (Note to programmers: normally, X errors are reported asynchronously;
   that is, you will receive the error a while after causing it.
   To debug your program, run it with the --sync command line
   option to change this behavior. You can then get a meaningful
   backtrace from your debugger if you break on the gdk_x_error() function.)
Launching a SCIM daemon with Socket FrontEnd...
Loading simple Config module ...
Creating backend ...
Loading socket FrontEnd module ...
Starting SCIM as daemon ...
GTK Panel of SCIM 1.4.9
--------------------------------------------------

==========================
Comment 49 Matthias Fulz 2010-05-12 08:58:34 UTC
(In reply to comment #45)
> (In reply to comment #44)
> > I had to add media-libs/libpng-1.4.2 to my overlay and change slot from 0 to
> > 1.4 and mask 1.2.43-r2.  Then 1.2.43 and 1.4.2 can co-exist happily.
> > 
> 
> Nobody needs to repeat your mistake, they can be installed slotted from Portage
> fine as-is,
> 
> $ sudo emerge -pv =libpng-1.2.43-r1 =libpng-1.4.2
> 
> These are the packages that would be merged, in order:
> 
> Calculating dependencies... done!
> [ebuild  NS   ] media-libs/libpng-1.2.43-r1 [1.4.2] 0 kB
> [ebuild   R   ] media-libs/libpng-1.4.2  0 kB
> 
> Total: 2 packages (1 in new slot, 1 reinstall), Size of downloads: 0 kB
> 

Ok, what's going on when you run after the above steps revdep-rebuild?

I'll tried it that way and about ~165 packages should be rebuild, and the second one (dunno which one it was, I'm working on this problem since sunday) stops...
Comment 50 Matthias Fulz 2010-05-12 09:10:35 UTC
(In reply to comment #43)
> <offtopic> (Feel free to ignore. That would only strengthen my argument. ;)

offtopic
I will not Ignore :D

> (In reply to comment #42)
> > Hey dude libpng-1.4.2 is ~amd64 ~x86, etc
> First of all, I’m not your dude. :)

Sorry, if I abused you, that wasn't my intention, so accept my appologies :)

> > I think the reason why you use it is you WANT TO TEST for others, because you
> > are an experienced user?
> Second: Agreed. :) Sorry, this is true in this case. I should have specified
> that I did mean this in general, for stable packages too.

Ok, that's a point and yes you are right with this, I had the problems
also in the past....

> > I really can only hope that you don't use unstable versions of ANY distribution
> > on critical servers?!
> No, I’m not insane. :) I would be as shocked as you. Unfortunately I tried
> stable, even hardened x86 on a dedicated testing server, to look it it would be
> an option to switch critical servers to it. After huge problems I switched it
> back to Debian. (And, yes, I am a very experienced user. I am usually the one
> giving support, not receiving it. :)
> 

On critical system I also prefer Debian, but to be honest, on a Desktop System Debian (stable) has much too old packages in 90% (dunno for other, I'm talking from my experiences) and if you are using unstable, testing, squeeze the package-manager could be a pain (one time it wanted to delete my half X-System and gnome, because some dependencies were not in the tree during my update-time) 

> > P.S.: libpng-1.2.43-r2 is working on my host perfectly (ok needed to rebuild
> > many packages, but that's something I know, instead I wouldn't use Gentoo if I
> > don't want to compile).
> Straw man argument. Nobody said I would not want to compile or that 1.2.x would
> not work. Even 1.4.x does work. The problem is that lots of packages still
> expect 1.2.x when only 1.4.x is installed, as their ebuild dependencies are
> apparently faulty.

Ok, that's really an argument, but that's life and I think I can live with it.
But that's something everybody need to decide for himself.

> I’d bet you money that you will fall over that one when 1.4.x is going
> stable, as I know how such incidents were handled in the past, and that in that
> regard, policies and mechanics haven’t changed.
> </offtopic>
> 

We will see ;)
And no I don't want to bet :P

/offtopic
Comment 51 Ferry 2010-05-12 13:26:18 UTC
(In reply to comment #48)
> with 1.4.2 installed only without 1.2: and after revdep-rebuild,
> /usr/sbin/libpng-1.4.x-update.sh, revdep-rebuild, 
> 
> gnome-panel 2.28/2.30(both) crashed immediately after desktop startup, showing

Not sure on where overlay bugs go, but I doubt it's here. 2.30 is not in portage and it's bugs don't appear related to libpng either. In either case, your report seems out of place here. You should probably take it up with the overlay maintainer.

Just that 2.28 crashes now too, might very well be because of one of the other packages it depends on comes from overlay. I have no issues any more, everything rebuilt fine.

You basically have several options

1) Install 1.2 and stay away from 1.4.
2) Try to get 1.2 and 1.4 next to each other.
3) Trying to get only 1.4.

The latter will require rebuilding a lot.
Middle one doesn't matter much
First one, if you rebuilt stuff against 1.4 already, it will have to be rebuilt against 1.2 again.


> ** GLib **: gmem.c:137: failed to allocate 187644257854905 bytes 

GLib is quite essential. I'm quite sure however that allocating 187 TERRAByte!!! isn't going to work on your system.

@Samuli

-r1 slots, -r2, which is the latest 1.2, does not slot however:

flaptoppy libpng # emerge =libpng-1.2.43-r1 =libpng-1.4.2 -pv

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

Calculating dependencies... done!
[ebuild  NS   ] media-libs/libpng-1.2.43-r1 [1.4.2] 0 kB
[ebuild   R   ] media-libs/libpng-1.4.2  0 kB

Total: 2 packages (1 in new slot, 1 reinstall), Size of downloads: 0 kB
flaptoppy libpng # emerge =libpng-1.2.43-r2 =libpng-1.4.2 -pv

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

Calculating dependencies... done!
[ebuild     UD] media-libs/libpng-1.2.43-r2 [1.4.2] 0 kB
[ebuild   R   ] media-libs/libpng-1.4.2  0 kB

Total: 2 packages (1 downgrade, 1 reinstall), Size of downloads: 0 kB

!!! Multiple package instances within a single package slot have been pulled
!!! into the dependency graph, resulting in a slot conflict:

media-libs/libpng:0

  ('ebuild', '/', 'media-libs/libpng-1.4.2', 'merge') pulled in by
    =libpng-1.4.2

  ('ebuild', '/', 'media-libs/libpng-1.2.43-r2', 'merge') pulled in by
    =libpng-1.2.43-r2


It may be possible to solve this problem by using package.mask to
prevent one of those packages from being selected. However, it is also
possible that conflicting dependencies exist such that they are
impossible to satisfy simultaneously. If such a conflict exists in the
dependencies of two different packages, then those packages can not be
installed simultaneously. You may want to try a larger value of the
--backtrack option, such as --backtrack=30, in order to see if that will
solve this conflict automatically.

For more information, see MASKED PACKAGES section in the emerge man page
or refer to the Gentoo Handbook.


Comment 52 Peter Levine 2010-05-13 05:25:17 UTC
After an initial revdep-rebuild, compilation failed on net-print/gnome-cups-manager which seemed to pick up -lpng12.  After debugging for quite a while I did a "grep -r 'png12' /usr/lib/*.la" and found -lpng12 listed in the dependency_libs section of la files owned by google-gadgets, glade, gnome-bluetooth, gnome-media, libgnomeui, and vte.  I remember that some if not all (certainly glade and google-gadgets) were previously emerged with revdep-rebuild.  But after a "revdep-rebuild -piv" none were listed to be emerged.  After manually unmerging and remerging the packages above, I was able to successfully build and install gnome-cups-manager.  Is this a bug?  Isn't revdep-rebuild supposed to pick those up after "revdep-rebuild -piv" ?
Comment 53 Tom-Steve Watzke 2010-05-13 10:20:36 UTC
Confirming stated crash of gnome-panel:
(In reply to comment #48)
> ---- Critical and fatal warnings logged during execution ----
> 
> ** GLib **: gmem.c:137: failed to allocate 187644257854905 bytes

I noticed the following:
$ ldd $(which gnome-panel) | grep png
	libpng12.so.0 => /usr/lib/libpng12.so.0 (0x00007fcdee502000)
	libpng14.so.14 => /usr/lib/libpng14.so.14 (0x00007fcde5545000)

That might be the issue, hopefully being solved by
(In reply to comment #52)
[...]
> for quite a while I did a "grep -r 'png12' /usr/lib/*.la" and found -lpng12

I just collected all issued packages by using the following commands, for which qfile from app-portage/portage-utils is needed:
todo=$(for i in $(grep -r "png12" *.la -l); do qfile -qC b $i; done | sort | uniq | grep -v ncurses); emerge -C $todo; emerge $todo

Before running you sould run this with the pretend flag: ...; emerge -Cp $todo; ...  to be sure no very important libs are removed (which are currently used).
I just added ncurses to "grep -v", which is important. Furthermore unmerge all old versions of libpng:
emerge -C '<media-libs/libpng-1.4'
Comment 54 Jeff Hayes 2010-05-14 16:49:05 UTC
(In reply to comment #53)

grep'ing *.la is not canonical source shared lib deps.  Try readelf instead.  :)


This will give you a nice list of pkgs dep on libpng12

 for i in $(find /lib* /usr/lib* -type f -name "lib*.so*"; find /bin* /usr/bin* -type f); do
	 a=$(readelf -d $i 2> /dev/null | grep libpng12)
	 if [[ -n "$a" ]]; then
		 qfile -qC $i
	 fi
done | sort | uniq
Comment 55 Stephan Friedrichs 2010-05-14 21:20:35 UTC
Today I tested libpng-1.2.43-r3 (without any other slot installed at the same time). revdep-rebuild (or reconcilio in my case) tried to rebuild quite a lot of packages, but almost all of them failed, because /usr/lib/libpng12.la was missing. When downgrading to libpng-1.2.43-r2, the .la file is there. I think the difference is the --disable-static in

src_configure() {
	econf \
		--disable-dependency-tracking \
		--disable-static
}

in the -r3 ebuild. Why doesn't the new revision install the .la files?
Comment 56 Benjamin Schulz 2010-05-15 15:08:48 UTC
another problem:

I had libpng 1.2.43-r2 installed. Portage wanted to upgrade to libpng 1.4 and deleted the 1.2 version. revdep-rebuild then tried to recompile a lot of packages but it failed, since some applications seemed to definitely want libpng 1.2.
So I manually unmerged lipng-1.4 and reinstalled  1.2.43-r2.

Today, portage wanted to pull in libpng 1.2.43-r3. Apparently it wanted to install the -r3 version in a new slot. This resultet in a blocker with the installed 1.2.43-r2 version.

So, I had to uninstall the r2 version and installed the 1.2.43-r3 version of lipng. 
At this point I unmasked libpng-1.4. Portage now wanted to install the 1.4 version in a new slot. So the 1.2.43-r3 did not get removed.
Revdep-rebuild did not want to compile anything and all went fine.


So I believe that this bug is a problem of the slots where the old libpng  1.2.43-r2 were installed to. They should go into other slots than the lipng-1.4 versions. 

Seeing that this is handled now with the -r3 revision of libpng, one should somehow tell portage to automatically replace the wrongly slotted -r2 version with the r3 ebuild. Portage should not report a blocker but do the update automatically.

Comment 57 Stephan Friedrichs 2010-05-15 15:33:27 UTC
(In reply to comment #56)
> Seeing that this is handled now with the -r3 revision of libpng, one should
> somehow tell portage to automatically replace the wrongly slotted -r2 version
> with the r3 ebuild. Portage should not report a blocker but do the update
> automatically.
> 

Not before the -r3 ebuild bothers to install the .la files, see comment #55...
Comment 58 Peter Ruskin 2010-05-16 09:24:48 UTC
Why has ">=media-libs/libpng-1.2.43-r2:0" been added to x11-libs/cairo, x11-libs/gtk+, x11-libs/qt-gui and  media-libs/libass?  I copied then to my overlay and removed the ":0" and the then emerged OK.
Comment 59 Arfrever Frehtes Taifersar Arahesis (RETIRED) gentoo-dev 2010-05-16 16:22:22 UTC
(In reply to comment #58)
> Why has ">=media-libs/libpng-1.2.43-r2:0" been added to x11-libs/cairo,
> x11-libs/gtk+, x11-libs/qt-gui and  media-libs/libass?

This dependency is correct.

Please continue your discussions in Gentoo Forums.
Comment 60 Christian Parpart (RETIRED) gentoo-dev 2010-05-22 08:32:13 UTC
t
Comment 61 Benny Pedersen 2010-05-22 19:20:01 UTC
currently as now there is no stable libpng left in portage tree all there is upgrades to unstable :(

1.2.40 should have staged longer in portage tree, until new version really is stable

here i have resolved by take the installed ebuild file from installed version over to my local overlay for now until it can be safely removed by me

is there not a 30 days testing period ?

such a problem here gets one to think its faster to leave gentoo and install os2 :)
Comment 62 SpanKY gentoo-dev 2010-05-23 01:39:20 UTC
you really need to read the actual ChangeLog and policy related to stabilization.  security and "important" issues do not require 30 days.
Comment 63 Permjacov E. A. 2010-05-27 06:54:06 UTC
(In reply to comment #42)
> (In reply to comment #41)
> I think the reason why you use it is you WANT TO TEST for others, because you
> are an experienced user?
There are other reasons for use ~arch. For example, the packages you _need_ for work may be only in ~arch. what should you do in such case?

Yep, I do know about per-package unmasking, but it deliviers you about same amount pain in ass, the only difference is a way it does it...

Ontopic:
I have same problems with update - no proper libpng12.la simlink, so many, many packages refuses to compile (no lpng12 found linker error). gdm/kdm refused to start, by the way.
Comment 64 Samuli Suominen gentoo-dev 2010-05-27 06:57:13 UTC
(In reply to comment #63)
> Ontopic:
> I have same problems with update - no proper libpng12.la simlink, so many, many
> packages refuses to compile (no lpng12 found linker error). gdm/kdm refused to
> start, by the way.

That's 100% off-topic, the *only* on-topic discussion here is at Comment #3:

http://bugs.gentoo.org/show_bug.cgi?id=319061#c3

Please use http://forums.gentoo.org/ instead.
Comment 65 Samuli Suominen gentoo-dev 2010-05-27 20:53:13 UTC

*** This bug has been marked as a duplicate of bug 286714 ***
Comment 66 Frank Hsieh 2011-03-30 15:56:21 UTC
(In reply to comment #23)
> I got many ld errors ... cannot find -lpng12 ...
> (I have both versions installed)
> Then I tried the following, since it needs the old one:
> cd /usr/lib
> ln -snvf libpng12.so.0.43.0 libpng12.so
> cd /usr/lib64
> ln -snvf libpng12.so.0.43.0 libpng12.so
> 
> THAT WORKED :D
> That means ld will find it for now, e.g.:
> ld -l png12
> will give other output than "not found".

It works for me.
x11-misc/notification-daemon complains "cannot find -lpng12".
My system only has libpng14.so.14.5.0.
I run "ln -snvf libpng14.so.14.5.0 libpng12.so" then I can emerge x11-misc/notification-daemon