Created attachment 306283 [details] build.log make[3]: Entering directory `/var/tmp/portage/media-gfx/graphviz-2.26.3-r3/work/graphviz-2.26.3/contrib/diffimg' CC diffimg.o CCLD diffimg diffimg.o: In function `imageLoad': /var/tmp/portage/media-gfx/graphviz-2.26.3-r3/work/graphviz-2.26.3/contrib/diffimg/diffimg.c:116: undefined reference to `gdImageCreateFromPng' /var/tmp/portage/media-gfx/graphviz-2.26.3-r3/work/graphviz-2.26.3/contrib/diffimg/diffimg.c:124: undefined reference to `gdImageCreateFromGif' diffimg.o: In function `main': /var/tmp/portage/media-gfx/graphviz-2.26.3-r3/work/graphviz-2.26.3/contrib/diffimg/diffimg.c:190: undefined reference to `gdImageCreate' /var/tmp/portage/media-gfx/graphviz-2.26.3-r3/work/graphviz-2.26.3/contrib/diffimg/diffimg.c:192: undefined reference to `gdImageColorAllocate' /var/tmp/portage/media-gfx/graphviz-2.26.3-r3/work/graphviz-2.26.3/contrib/diffimg/diffimg.c:193: undefined reference to `gdImageColorAllocate' diffimg.o: In function `imageDiff': /var/tmp/portage/media-gfx/graphviz-2.26.3-r3/work/graphviz-2.26.3/contrib/diffimg/diffimg.c:159: undefined reference to `gdImageGetTrueColorPixel' /var/tmp/portage/media-gfx/graphviz-2.26.3-r3/work/graphviz-2.26.3/contrib/diffimg/diffimg.c:159: undefined reference to `gdImageGetTrueColorPixel' /var/tmp/portage/media-gfx/graphviz-2.26.3-r3/work/graphviz-2.26.3/contrib/diffimg/diffimg.c:161: undefined reference to `gdImageSetPixel' diffimg.o: In function `main': /var/tmp/portage/media-gfx/graphviz-2.26.3-r3/work/graphviz-2.26.3/contrib/diffimg/diffimg.c:202: undefined reference to `gdImagePng' /var/tmp/portage/media-gfx/graphviz-2.26.3-r3/work/graphviz-2.26.3/contrib/diffimg/diffimg.c:206: undefined reference to `gdImagePng' /var/tmp/portage/media-gfx/graphviz-2.26.3-r3/work/graphviz-2.26.3/contrib/diffimg/diffimg.c:212: undefined reference to `gdImageDestroy' /var/tmp/portage/media-gfx/graphviz-2.26.3-r3/work/graphviz-2.26.3/contrib/diffimg/diffimg.c:213: undefined reference to `gdImageDestroy' /var/tmp/portage/media-gfx/graphviz-2.26.3-r3/work/graphviz-2.26.3/contrib/diffimg/diffimg.c:214: undefined reference to `gdImageDestroy' /var/tmp/portage/media-gfx/graphviz-2.26.3-r3/work/graphviz-2.26.3/contrib/diffimg/diffimg.c:196: undefined reference to `gdImageFilledRectangle' collect2: ld returned 1 exit status make[3]: *** [diffimg] Error 1 make[3]: Leaving directory `/var/tmp/portage/media-gfx/graphviz-2.26.3-r3/work/graphviz-2.26.3/contrib/diffimg' "revdep-rebuild -i" does NOT report that media-libs/gd needs to be recompiled. This is similar to bug #406959 but I do have "media-libs/gd +zlib" already on my system installed. In build.log I see: checking for gdlib-config... /usr/bin/gdlib-config checking gd.h usability... yes checking gd.h presence... yes checking for gd.h... yes checking for main in -lgd... no configure: WARNING: Optional GD library not available But it doesn't look this is really optional. # /usr/bin/gdlib-config --libdir /usr/lib64 # /usr/bin/gdlib-config --includedir /usr/include # /usr/bin/gdlib-config --ldflags -Wl,-O1 -Wl,--as-needed -lpng14 # /usr/bin/gdlib-config --libs -lXpm -lX11 -ljpeg -lfontconfig -lfreetype -lz -lm # /usr/bin/gdlib-config --cflags -I/usr/include # /usr/bin/gdlib-config --includes -I/usr/include # /usr/bin/gdlib-config --features GD_XPM GD_JPEG GD_FONTCONFIG GD_FREETYPE GD_PNG GD_GIF GD_GIFANIM GD_OPENPOLYGON #
Created attachment 306285 [details] config.log
# emerge -pv gd graphviz These are the packages that would be merged, in order: Calculating dependencies... done! [ebuild R ] media-libs/gd-2.0.35-r3 USE="fontconfig jpeg png truetype xpm zlib -static-libs" 0 kB [ebuild N ] media-gfx/graphviz-2.26.3-r3 USE="gtk java perl python tcl -cairo -doc -examples -lasi -nls -ruby -static-libs" 0 kB # Well, revdep-rebuild is out of question, because I unmerged graphviz meanwhile, so it has no chance to do anything about its requirements. So this either an ebuild or media-libs/gd issue.
(In reply to comment #0) > # /usr/bin/gdlib-config --ldflags > -Wl,-O1 -Wl,--as-needed -lpng14 # ls -la /usr/lib/libpng* lrwxrwxrwx 1 root root 11 Mar 12 01:37 /usr/lib/libpng.so -> libpng15.so -rwxr-xr-x 1 root root 158400 Mar 12 01:37 /usr/lib/libpng14.so.14 lrwxrwxrwx 1 root root 18 Mar 12 01:37 /usr/lib/libpng15.so -> libpng15.so.15.9.0 lrwxrwxrwx 1 root root 18 Mar 12 01:37 /usr/lib/libpng15.so.15 -> libpng15.so.15.9.0 -rwxr-xr-x 1 root root 174920 Mar 12 01:37 /usr/lib/libpng15.so.15.9.0 # Could it be related to libpng14.so.14 left in the filesystem? Indeed! /var/tmp/portage/media-gfx/graphviz-2.26.3-r3/work/graphviz-2.26.3/config.log shows that: conftest.c:147: warning: function declaration isn't a prototype /usr/lib/gcc/x86_64-pc-linux-gnu/4.3.6/../../../../x86_64-pc-linux-gnu/bin/ld: cannot find -lpng14 collect2: ld returned 1 exit status configure:25397: $? = 1 configure: failed program was: | /* confdefs.h */ | #define PACKAGE_NAME "graphviz" | #define PACKAGE_TARNAME "graphviz" | #define PACKAGE_VERSION "2.26.3" Why doesn't libpng cleanup properly its stuff during upgrade? Shouldn't it leave /usr/lib/libpng14.so symlink existing? [ebuild R ] media-libs/libpng-1.5.9 USE="-apng (-neon) -static-libs" 0 kB So I am anyways blaming "revdep-rebuild -i". ;)
When you upgraded from =media-libs/libpng-1.4* to =media-libs/libpng-1.5* there was a message printed that you should run `revdep-rebuild --library libpng14.so.14` and then manually delete the libpng14.so.14. Then there was the Portage News Item about the upgrade: http://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo-news/2011/2011-10-15-libpng15/2011-10-15-libpng15.en.txt?revision=57&view=markup Where it says: # revdep-rebuild --library libpng14.so.14 -- --keep-going And also: Note: It might be necessary to run the previous command more than once. When followed correctly, it would have rebuilt media-libs/gd against =media-libs/libpng-1.5* and `gdlib-config --libs` will print -lpng15 instead of -lpng14 Then there is the forums thread for these type of upgrade issues as bugzilla is not helpdesk (no offense): http://forums.gentoo.org/viewtopic-t-894950.html In other words, no bug here, just incomplete libpng upgrade which requires the announced manual steps.
(In reply to comment #4) > When you upgraded from =media-libs/libpng-1.4* to =media-libs/libpng-1.5* > there was a message printed that you should run `revdep-rebuild --library > libpng14.so.14` and then manually delete the libpng14.so.14. > > Then there was the Portage News Item about the upgrade: > > http://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo-news/2011/2011-10-15- > libpng15/2011-10-15-libpng15.en.txt?revision=57&view=markup > > Where it says: > > # revdep-rebuild --library libpng14.so.14 -- --keep-going Why isnt' "rebuild -i" enough? Because it would only look for libpng14.so? > And also: > > Note: It might be necessary to run the previous command more than once. > > When followed correctly, it would have rebuilt media-libs/gd against > =media-libs/libpng-1.5* and `gdlib-config --libs` will print -lpng15 instead > of -lpng14 > > Then there is the forums thread for these type of upgrade issues as bugzilla > is not helpdesk (no offense): > > http://forums.gentoo.org/viewtopic-t-894950.html Sad reading. The gentoo build system should really work more automatically. While being a sci overlay contributer I do contribute already but this is one thing I really do not like on Gentoo. Sorry to say that. I cannot handle 32 nodes in a cluster under STABLE amd64. :( I've just spent 2 weeks on fixing the nodes, individually, one by one. > > In other words, no bug here, just incomplete libpng upgrade which requires > the announced manual steps. Why can't I keep the old libs? I strongly don't like apps not starting up when they cannot find their dynamic lib. I can re-compile them to use newer libs when I have time, or when "emerge -uN world" or "revdep-rebuild -i" gets to them (usually after several exits on blocked/no compiling packages). Anyway, this doesn't explain why is there the /usr/lib/libpng14.so symlink. That is intentional?
(In reply to comment #5) > (In reply to comment #4) > > When you upgraded from =media-libs/libpng-1.4* to =media-libs/libpng-1.5* > > there was a message printed that you should run `revdep-rebuild --library > > libpng14.so.14` and then manually delete the libpng14.so.14. > > > > Then there was the Portage News Item about the upgrade: > > > > http://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo-news/2011/2011-10-15- > > libpng15/2011-10-15-libpng15.en.txt?revision=57&view=markup > > > > Where it says: > > > > # revdep-rebuild --library libpng14.so.14 -- --keep-going > > Why isnt' "rebuild -i" enough? Because it would only look for libpng14.so? Because the libpng14.so.14 was kept around there is no broken dynamic linking. > > > > And also: > > > > Note: It might be necessary to run the previous command more than once. > > > > When followed correctly, it would have rebuilt media-libs/gd against > > =media-libs/libpng-1.5* and `gdlib-config --libs` will print -lpng15 instead > > of -lpng14 > > > > Then there is the forums thread for these type of upgrade issues as bugzilla > > is not helpdesk (no offense): > > > > http://forums.gentoo.org/viewtopic-t-894950.html > > Sad reading. The gentoo build system should really work more automatically. > While being a sci overlay contributer I do contribute already but this is > one thing I really do not like on Gentoo. Sorry to say that. I cannot handle > 32 nodes in a cluster under STABLE amd64. :( I've just spent 2 weeks on > fixing the nodes, individually, one by one. Portage doesn't have a feature where one could say "If package foo gets upgraded, package bar must be recompiled." and that's bug 192319. The way to do this now is to print the revdep-rebuild --library instruction and/or @preserved-libs in Portage 2.2.x series. > > > > > In other words, no bug here, just incomplete libpng upgrade which requires > > the announced manual steps. > > Why can't I keep the old libs? I strongly don't like apps not starting up > when they cannot find their dynamic lib. I can re-compile them to use newer > libs when I have time, or when "emerge -uN world" or "revdep-rebuild -i" > gets to them (usually after several exits on blocked/no compiling packages). > > Anyway, this doesn't explain why is there the /usr/lib/libpng14.so symlink. > That is intentional? Yes it's intentional. Keeping the matching SONAME file is enough: objdump -p /usr/lib/libpng14.so.14 |grep SONAME To keep the existing dynamic linking intact, while waiting for the user to do the revdep-rebuild --library libpng14.so.14 & rm -f libpng14.so.14 upgrade steps. If you were to add that symlink now, packages would compile using the headers from libpng15, and then `gdlib-config` would print -lpng14 and packages would end up mixing headers & library from incompatible versions... Basically you end up with broken system if you create such symlink now. Gentoo doesn't support building/linking against libpng14 anymore, and in fact, any traces of libpng14 have been removed from Portage and the library is actually vulnerable too wrt bug 404197. Thus everything you still have linked against it, is potentially exploitable too.
(In reply to comment #6) > (In reply to comment #5) > > (In reply to comment #4) > > > When you upgraded from =media-libs/libpng-1.4* to =media-libs/libpng-1.5* > > > there was a message printed that you should run `revdep-rebuild --library > > > libpng14.so.14` and then manually delete the libpng14.so.14. > > > > > > Then there was the Portage News Item about the upgrade: > > > > > > http://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo-news/2011/2011-10-15- > > > libpng15/2011-10-15-libpng15.en.txt?revision=57&view=markup > > > > > > Where it says: > > > > > > # revdep-rebuild --library libpng14.so.14 -- --keep-going > > > > Why isnt' "rebuild -i" enough? Because it would only look for libpng14.so? > > Because the libpng14.so.14 was kept around there is no broken dynamic > linking. Hmm. True. > > > > > > > > And also: > > > > > > Note: It might be necessary to run the previous command more than once. > > > > > > When followed correctly, it would have rebuilt media-libs/gd against > > > =media-libs/libpng-1.5* and `gdlib-config --libs` will print -lpng15 instead > > > of -lpng14 > > > > > > Then there is the forums thread for these type of upgrade issues as bugzilla > > > is not helpdesk (no offense): > > > > > > http://forums.gentoo.org/viewtopic-t-894950.html > > > > Sad reading. The gentoo build system should really work more automatically. > > While being a sci overlay contributer I do contribute already but this is > > one thing I really do not like on Gentoo. Sorry to say that. I cannot handle > > 32 nodes in a cluster under STABLE amd64. :( I've just spent 2 weeks on > > fixing the nodes, individually, one by one. > > Portage doesn't have a feature where one could say "If package foo gets > upgraded, package bar must be recompiled." and that's bug 192319. > The way to do this now is to print the revdep-rebuild --library instruction > and/or @preserved-libs in Portage 2.2.x series. > > > > > > > > > In other words, no bug here, just incomplete libpng upgrade which requires > > > the announced manual steps. > > > > Why can't I keep the old libs? I strongly don't like apps not starting up > > when they cannot find their dynamic lib. I can re-compile them to use newer > > libs when I have time, or when "emerge -uN world" or "revdep-rebuild -i" > > gets to them (usually after several exits on blocked/no compiling packages). > > > > Anyway, this doesn't explain why is there the /usr/lib/libpng14.so symlink. ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ is NOT (I wanted to say, sorry) > > That is intentional? > > Yes it's intentional. Keeping the matching SONAME file is enough: > > objdump -p /usr/lib/libpng14.so.14 |grep SONAME I don't get it. :( *.la files point just to -lpng14 so how do they learn that /usr/lib/libpng14.so.14 is what they want? I think what you describe is ithe opposite "resolving" direction. > > To keep the existing dynamic linking intact, while waiting for the user to > do the revdep-rebuild --library libpng14.so.14 & rm -f libpng14.so.14 > upgrade steps. > > If you were to add that symlink now, packages would compile using the > headers from libpng15, and then `gdlib-config` would print -lpng14 and I don't get it, why? `gdlib-config` would points to -lnpg14 until gd is reinstalled (against libpng15.so) but that fails currently because of the missing symlink (ln -s libpng14.so.14 libpng14.so). > packages would end up mixing headers & library from incompatible versions... > Basically you end up with broken system if you create such symlink now. > > Gentoo doesn't support building/linking against libpng14 anymore, and in > fact, any traces of libpng14 have been removed from Portage and the library > is actually vulnerable too wrt bug 404197. Thus everything you still have > linked against it, is potentially exploitable too. On a brand new ~amd64 I have: # ls -la /usr/lib/libpng* lrwxrwxrwx 1 root root 11 Feb 26 13:32 /usr/lib/libpng.so -> libpng15.so -rwxr-xr-x 1 root root 182106 Mar 18 01:41 /usr/lib/libpng12.so.0 lrwxrwxrwx 1 root root 18 Feb 26 13:32 /usr/lib/libpng15.so -> libpng15.so.15.9.0 lrwxrwxrwx 1 root root 18 Feb 26 13:32 /usr/lib/libpng15.so.15 -> libpng15.so.15.9.0 -rwxr-xr-x 1 root root 211505 Feb 26 13:32 /usr/lib/libpng15.so.15.9.0 # equery belongs libpng12.so.0 * Searching for libpng12.so.0 ... app-emulation/emul-linux-x86-baselibs-20120127 (/usr/lib32/libpng12.so.0) app-emulation/vmware-workstation-8.0.2.591240 (/opt/vmware/lib/vmware/lib/libpng12.so.0/libpng12.so.0) app-emulation/vmware-workstation-8.0.2.591240 (/opt/vmware/lib/vmware/lib/libpng12.so.0) #
(In reply to comment #7) > > > Anyway, this doesn't explain why is there the /usr/lib/libpng14.so symlink. > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ is NOT (I wanted to say, sorry) > > > That is intentional? > > Yes it's intentional. Keeping the matching SONAME file is enough: > > > > objdump -p /usr/lib/libpng14.so.14 |grep SONAME > > I don't get it. :( *.la files point just to -lpng14 so how do they learn > that /usr/lib/libpng14.so.14 is what they want? I think what you describe is > ithe opposite "resolving" direction. The .la file issue is bug 319101 and the first post of the upgrade thread covers solving them (replacing every instance of -lpng14 with -lpng15): http://forums.gentoo.org/viewtopic-t-894950.html And as prev. noted, it's covered in the Portage News Item too. > > To keep the existing dynamic linking intact, while waiting for the user to > > do the revdep-rebuild --library libpng14.so.14 & rm -f libpng14.so.14 > > upgrade steps. > > > > If you were to add that symlink now, packages would compile using the > > headers from libpng15, and then `gdlib-config` would print -lpng14 and > I don't get it, why? `gdlib-config` would points to -lnpg14 until gd is > reinstalled (against libpng15.so) but that fails currently because of the > missing symlink (ln -s libpng14.so.14 libpng14.so). If gd was built against libpng14, the -lpng14 gets injected into it's build system, to the gdlib-config. When your recompile gd, it will change to -lpng15. It fails because you haven't rebuilt it, not because there is missing symlink. Symlinking is nearly ever anykind of solution, but the most stupidest thing I can think of in that situation. > > packages would end up mixing headers & library from incompatible versions... > > Basically you end up with broken system if you create such symlink now. > > > > Gentoo doesn't support building/linking against libpng14 anymore, and in > > fact, any traces of libpng14 have been removed from Portage and the library > > is actually vulnerable too wrt bug 404197. Thus everything you still have > > linked against it, is potentially exploitable too. > > > On a brand new ~amd64 I have: > > # ls -la /usr/lib/libpng* > lrwxrwxrwx 1 root root 11 Feb 26 13:32 /usr/lib/libpng.so -> libpng15.so > -rwxr-xr-x 1 root root 182106 Mar 18 01:41 /usr/lib/libpng12.so.0 > lrwxrwxrwx 1 root root 18 Feb 26 13:32 /usr/lib/libpng15.so -> > libpng15.so.15.9.0 > lrwxrwxrwx 1 root root 18 Feb 26 13:32 /usr/lib/libpng15.so.15 -> > libpng15.so.15.9.0 > -rwxr-xr-x 1 root root 211505 Feb 26 13:32 /usr/lib/libpng15.so.15.9.0 > # equery belongs libpng12.so.0 > * Searching for libpng12.so.0 ... > app-emulation/emul-linux-x86-baselibs-20120127 (/usr/lib32/libpng12.so.0) > app-emulation/vmware-workstation-8.0.2.591240 > (/opt/vmware/lib/vmware/lib/libpng12.so.0/libpng12.so.0) > app-emulation/vmware-workstation-8.0.2.591240 > (/opt/vmware/lib/vmware/lib/libpng12.so.0) > # Indeed, looks fine. As you can see there is no libpng12.so either, just libpng12.so.0 which is the SONAME from `objdump -p /usr/lib/libpng12.so.0` required for dynamic linking of binary-only precompiled software you can't rebuild against libpng15. It's merely a temporary backwards compability for binary-only apps. This is really all as designed and there is no working around the upgrade, with symlinks or anything else, it must be done correctly by rebuilding every source based application against libpng15, -lpng15, libpng15.so, libpng15 headers etc. And again, this is not forums. The help is available in the forums post if something is still unclear.
Thanks for your thorough guidance.
