Description of problem: When starting an instance of TBrowser, root complains of a version mismatch for libpng Version-Release number of selected component (if applicable): root-graf-asimage-5.32.03-1.fc17.x86_64 How reproducible: Always Steps to Reproduce: 1. Create a root script which generates a .png file e.g. create_png.C: void create_png() { TCanvas *c = new TCanvas(); TText *t = new TText(.5,.5,"test"); t->Draw(); c->SaveAs("test.png"); c->SaveAs("test.gif"); } 2. root create_png.C Actual results: libpng warning: Application built with libpng-1.2.44 but running with 1.5.10 Info in <TCanvas::Print>: file test.png has been created Info in <TCanvas::Print>: GIF file test.gif has been created Indeed two files are created, test.png and test.gif. The .gif file has the expected content, but the .png file has zero length. Expected results: A .png file which looks like the .gif one. Additional info: libpng-1.5.10-1.fc17.x86_64 is indeed installed on the system, but libpng-1.2.44 is not. The error message is produced by libpng itself. There is, however, /usr/lib64/libpng12.so.0.49.0 which belongs to the libpng-compat package, which is required by libAfterImage-devel-1.20-2.fc15.x86_64 and libAfterImage-devel is a BuildRequires for root. Workaround: start root with: LD_PRELOAD=/usr/lib64/libpng12.so.0.49.0 root Note, that I get the same error (with the same 1.2.44 version), whether I use the official fedora-update version or if I build it myself on a system which does not have version 1.2.44!
Hmmm, it seems that /usr/lib64/libAfterImage.so has some sort of embedded libpng in it. That is from libAfterImage-1.20-2.fc17.x86_64 (and the -devel package).
So I tried to build libAfterImage from source rpm and it failed. However, it seems that this problem is known to the root people: http://root.cern.ch/viewvc?view=rev&revision=40326 Applying that patch makes it possible to build libAfterImage and it now picks up the same version number for libpng as the installed one i.e. 1.5.10. So it seems that libAfterImage _must_ always be recompiled after upgrading libpng. I guess this should be a bug filed against libAfterImage, not root, after all.
*** This bug has been marked as a duplicate of bug 817780 ***