Libpng conflict

Dear experts,

I updated ROOT today to 5.34-14 and unfortunately a conflict with libpng rose.
In fact, when I want to save a png it says:

libpng warning: Application built with libpng-1.6.8 but running with 1.5.17 Error in <TASImage::WriteImage>: error writing file multineutrons.png Info in <TCanvas::Print>: png file multineutrons.png has been created libpng warning: Application built with libpng-1.6.8 but running with 1.5.17 Error in <TASImage::WriteImage>: error writing file neutronsMultisensitivity.png

I’m on OS X 10.8.2 and I use macports. I have already uninstalled libpng 1.5.17 and recompiled both latest version of ROOT and 5.34-12 but nothing changed.

What am I missing?

Have you reinstalled ROOT yourself ?

Yes I have.

Anyway I noticed that apparently the conflict existed between libpng version activated by macports (1.6.8), and the one used by X11/XQuartz (1.5.17).
Downgrading macports libpng version to 1.5.17 and then recompiling ROOT did the trick.

This issue is solved.

Hi, sorry to reopen this issue, but I’m having the sampe problem now:

libpng warning: Application built with libpng-1.5.18 but running with 1.6.10

I’m compiling 5-34-18 under Mavericks, disabling cocoa because it does horrible things to the layout of my plots, enabling builtin freetype because otherwise it doesn’t compile, and disabling fink, whatever that does (I have homebrew).

./configure --enable-roofit --enable-table --enable-opengl --disable-cocoa --enable-builtin-freetype --disable-fink

I have modified the configure script to pick up libpng 1.6.10, but that didn’t help:
$ grep -i png configure.log
Checking for png.h … /usr/local/Cellar/libpng/1.6.10/include
Checking for libpng … /usr/local/Cellar/libpng/1.6.10/lib

I don’t understand where the conflict comes from. I’ve tried giving it a couple of different libpng’s, including the one XQuartz uses, but the error message never changes.

How can I figure out which version is being picked up by root at run time? I tried “otool -L”, and “export DYLD_PRINT_LIBRARIES=1”, but it doesn’t seem to be using libpng at all.

Any ideas?


Cocoa is fine for me now. What kind of “horrible things” do you get ?

On my Mavericks machine libpng is found in /usr/local/lib and the include in /usr/local/include


For me, that location is a symlink to the homebrew version:
/usr/local/lib/libpng.dylib -> …/Cellar/libpng/1.6.10/lib/libpng.dylib

But there is no way to have a standalone png or so? Because, when you configure with cocoa, it doesn’t seem to use the libpng, and also it works…

For the plots with cocoa, there are currently two things:

  1. All spacings are changed, so that my previous plots look ugly. I guess that could be fixed by retuning. See the 33 and 27 errors in the attached example- they are closer together in non-cocoa.

  2. In one axis label, I want to display an angle, as “#gamma [#circ]”. But it renders as “#gamma [#circ ]”. Notice the long whitespace after #circ.

gammacombo_dsk_sfit_g.C (587 Bytes)

with the macro you sent I get exactly the same thing with X11 or cocoa. See attached screen dump

Ah, sorry, I uploaded my earlier test example again… Here’s the correct macro.
gammacombo_dsk_sfit_g.C (57.5 KB)


I solved the libpng conflict. I think the problem was that when Root builds the libAfterImage, it somehow doesn’t tell libAfterImage which version of libpng should be used. This is probably because the configure script of libAfterImage is not flexible enough. So libAfterImage picked up some libpng from a default location, while at runtime it tried to find the libpng that was configured by Root.

Solved like this:

  1. configure Root (from fresh 5-34-18 sources)
    ./configure --enable-roofit --enable-table --enable-opengl --disable-cocoa --enable-builtin-freetype

  2. make Root. This makes the version that suffers from the conflict.
    make -j4

  3. I had patched the libAfterImage configure script to print out the options it is being called with. Then I add --with-builtin-png=yes and build again
    cd graf2d/asimage/src/libAfterImage
    make clean
    ./configure --with-ttf --with-ttf-includes=-I…/…/…/…/graf2d/freetype/src/freetype-2.3.12/include --with-afterbase=no --without-svg --disable-glx --with-builtin-ungif --with-jpeg --with-jpeg-includes=/usr/local/include --with-png --with-png-includes=/usr/local/include --with-tiff-includes=/usr/local/include --with-builtin-png=yes

  4. Go back to root directory and call make again to pick up the new libAfterImage:
    cd -
    make -j4


You new macro gives me the same result with both X11 and Cocoa (X11 left Cocoa right)
Note that the legend on left looks different because I am debugging it right now.
It is the same otherwise


Mmh, that’s interesting. For me, there’s definitely a difference, see screenshot. I’m using root-5-34-18, both compiled on my machine, one time with cocoa, and the other one without (and with builtin libpng instead…)

Is it perhaps because it’s on a retina display? I also checked the PDF, and that also has the issues, so it’s probably not just a display issue.


do you have the very latest download ? this issue has been fixed very recently with cocoa

Hi Olivier,

I’ve downloaded root 5-34-18 from … ersion-534

on June 1st. Is that recent enough or what do you mean?


yes it should be fine.
I just tried on a retina display to be sure.
The x axis title looks fine. No extra space before ]

That’s quite annoying… how does one debug something like this? But I can live without cocoa for now.

Seems to me there is nothing to debug as it is working …

Hi, ok with the current 5.34 patch branch it indeed seems to work, no space in front of ] anymore. Also, for some reason, the libpng conflict has disappeared.

But I noticed another issue with cocoa and pixel fonts. See the position of the bracket in front of the #chi in the attached macro. It moves from the left of #chi to the right of #chi!

Also, when I save this as png or jpg on my retina display, only the top left quarter gets saved…


chibracket.C (675 Bytes)