Root XPM error on Ubuntu revisited

I’ve read all the threads about people having problems with not being able to start a TBrowser when building ROOT from source in Ubuntu. I’m having the same problem and none of the suggestions I’ve found in the relevant threads seem to help. (Didn’t want to dredge up one of the old threads.) I’m using Edgy, and so gcc is version 4.1.2.

I’ve tried all the suggested solutions, such as building with --prefix instead of building with ROOTSYS, building it to go into my home directory, and nothing seems to help.

Right now my copy is built for debug, but I’m not sure what debug dumps are relevant to the situation.

Asimage has been built and is installed, so I can’t imagine that’s the problem.

Any help would be appreciated.


You may try with the package provided for the “edgy” users at

Cheers, Ilka

I’m aware of the bnl pre-built packages, however, I would prefer to be able to build an arbitrary version of root myself, as I need to be able to compile minossoft, which expects root to be installed in $ROOTSYS.

Here are some clarifications:
The ubuntu packages in the bnl repository work for me, so obviously it is not impossible to make ROOT work on Ubuntu. However, I do not wish for this to be a permanent solution, and it also does not work for my AMD64 machine. (I suppose I could try building the source packages from the repository, but I would really rather just build a vanilla ROOT install from the .tar.gz files provided.) To me this indicates some small error in the build system or install scripts that ubuntu exposes, since the packaged version works.

The error I’m seeing is the same as others have seen. Currently I have root 5.14/00c compiled and installed with $ROOTSYS=/usr/local/root

root [0] TBrowser t; Error in <TGVScrollBar::TGVScrollBar>: arrow_*.xpm not found

Would a debugging trace help? Build logs? Anything else? I did a strace but it didn’t have any errors that seemed to be pertinent in it. Also, root loads its splash screen just fine, so it can find its xpm files.

I’m using ROOT in an Ubuntu edgy, compiled from sources, without using particular recipes.

I setted the ROOTSYS variable before run the ./configure script, and than I use the normal commands:

$ make
$ sudo make install

That’s exactly what I did. What could the difference between our systems be?

uhm… i don’t have any great Idea, if you ./configure have success you have all -dev package needed, i.e. libxpm-dev.

thiese are the options that I used to configure ROOT:

–enable-mathcore --enable-mathmore --enable-minuit2 --enable-xml --enable-cintex --enable-python --enable-opengl --enable-krb5 --enable-minuit2 --enable-rfio --enable-rpath --enable-soversion --enable-unuran --enable-asimage --enable-roofit --enable-astiff --enable-asimage --disable-builtin-afterimage --disable-builtin-freetype --enable-table --enable-reflex

and I setted

export ROOTSYS=/opt/root

before any new attempt I suggest to use

$ make distclean

I had tried distclean-ing, and also removing and re-un-tarring the source tree.

Is there anything outside of $ROOTSYS that I should be concerned with removing? As far as I can tell, there is not.


try to install libxt-dev, remove asimage/src/libAfterImage and related asimage stuff and rebuild. What I believe happens is that you have afterimage compiled with X_DISPLAY_MISSING (you can check libAfterImage/config.log file) The problem in TASImage is that it assumes it can use asimage2pixmap function while it does nothing in case of X_DISPLAY_MISSING.


Jiri, many thanks! :smiley:
Your advice was spot on. X_DISPLAY_MISSING was indeed set, and after installing libxt-dev, it is not. ROOT works fine now! I didn’t even realize there was a config.log in there.

For other ubuntu users, I might suggest installing xorg-dev, which drags in all of the xorg development dependencies with it, including libxt-dev, although I did not need them all for ROOT to work.

I would like to confirm that things also worked for me (finally) in kubuntu dapper drake with ROOT 5.15/04. Thanks to everybody who tried to find a solution…


maybe the top level configure could check for the same X header file as libAfterImage does - I believe it was X11/Intrinsic.h - to ensure that the build of libAfterImage is functional. In fact I did not check whether this header is really essential for afterimage - it might be just a random pick from the X11 headers that it should check for something else.



I will change the main configure to make sure these X11 files are available. it seems Ubuntu has some finer grain X11-dev packaging then RedHat, for which we do currently the checking.

Cheers, Fons.