Could you please let me know the OS you are installing on?

Oh, and also the version ... is this 0.2.4?

It's a GNU/Linux machine; and yes, 0.2.4.

What linux?

Linux version 2.6.18-194.26.1.el5 (mockbuild@builder10.centos.org) (gcc version 4.1.2 20080704 (Red Hat 4.1.2-48))

Try doing

source env.sh
python ${MAUS_THIRD_PARTY}/third_party/install/bin/library_finder.py Xcomp
bash ${MAUS_ROOT_DIR}/third_party/bash/21root.bash

Can I have the full install_log_std file please?

Chris's solution -- library_finder.py Xcomp -- works.

Gene -- is this on the vejur cluster?

If so, the problem was the following:
there's a freeNX installation on the machine;
21root.bash->library_finder picked up /usr/NX/libX11 (before /usr/lib64) and make a link
however the default ld library path does not include /usr/NX/lib
hence when trying to link against the nx x11, it could not find associate libraries

The reason I never saw it was because I had set maus_third_party to an earlier build

The next time you try to install, you'll probably run into the same issue.
You can either
a) follow Chris's solution above or
b) do export LD_LIBRARY_PATH=${LD_LIBRARY_PATH}:/usr/NX/lib before you run the installer, or
c) use an earlier third party build by setting maus_third_party or

If you want to use the standard X11 libraries,
you have to modify the root install script to disable lib finder and instead set x11 to
the standard library location

Chris: I tried your suggestion, but still got the same error.
Durga: I did b) and it built just fine.

You can close this issue.

Thanks guys.

Ah well, the idea behind the library_finder.py was to avoid this sort of crap. It seems that every linux distribution has it's favourite way of naming the lib directory structure (/usr/lib/i386_linux/ /usr/lib32/ /usr/local/lib ...) so I just made a script that would search /usr/ for relevant libraries. If I missed a library off the list, would be great to know about it. It's a bit hacky, but the alternative is to try to figure out every variant on 32bit/64bit/random naming conventions, which also seems like it will be a disaster. I chose the one I guessed would be lower maintenance.

I can add Xcomp to the list (as the next person to try this will probably hit the same problem). Maybe it needs specifically libXcomp.so.3?

Just libXcomp.so works fine -- it exists as a symbolic link to libXcomp.so.3
Will library_finder exit if it does not find a libXcomp -- as it won't on default SL?

Won't `uname -m` work for finding the architecture?
Something like:
if [ `uname -m` == "x86_64" ]; then x11="/usr/lib64"; else x11="/usr/lib"; fi
At least on SLF and CentOS uname -m returns x86_64 for 64-bit and i386/i586/i686 for 32-bit
and the X11 libraries are in /usr/lib64 or /usr/lib

For ROOT, you can also just configure with
--enable-x11 (on by default) and --enable-xft
and it should pick up the appropriate libraries.
Xext is a problem because there is no enable-xext and you need to specify the library path

There was a problem with ubuntu, and IIRC suse is different also. So although we don't explicitly support these distros, I would like to do so (if only because I use Ubuntu and OpenSUSE).

Right, library_finder gives an error if it can't find the appropriate lib. I can make that a command line flag...

nb: the same problem exists in GEANT4 OpenGL support - so if we ever want to have native OpenGL support (which we do want), we need to jump through similar hoops.