Project

General

Profile

Support #1009

MAUS build failure

Added by Rogers, Chris over 10 years ago. Updated over 10 years ago.

Status:
Closed
Priority:
Normal
Assignee:
Category:
Build System
Target version:
Start date:
12 June 2012
Due date:
% Done:

100%

Estimated time:
(Total: 0.00 h)
Workflow:
New Issue

Description

Hi Chris,

I'm having trouble installing the latest MAUS. From the end of the install_log, I get the message pasted below.
I'm not quite sure what the problem is.

Gene

/usr/bin/ld: warning: libXcomp.so.3, needed by /home/gkafka/maus/third_party/install/lib//libX11.so, not found (try using -rpath or -rpath-link)
/home/gkafka/maus/third_party/install/lib//libX11.so: undefined reference to `NXTransReadable'
/home/gkafka/maus/third_party/install/lib//libX11.so: undefined reference to `NXTransFlush'
/home/gkafka/maus/third_party/install/lib//libX11.so: undefined reference to `NXTransWrite'
/home/gkafka/maus/third_party/install/lib//libX11.so: undefined reference to `_NXDisplayErrorFunction'
/home/gkafka/maus/third_party/install/lib//libX11.so: undefined reference to `NXTransPrepare'
/home/gkafka/maus/third_party/install/lib//libX11.so: undefined reference to `NXTransSelect'
/home/gkafka/maus/third_party/install/lib//libX11.so: undefined reference to `NXTransClose'
/home/gkafka/maus/third_party/install/lib//libX11.so: undefined reference to `NXTransCreate'
/home/gkafka/maus/third_party/install/lib//libX11.so: undefined reference to `_NXHandleDisplayError'
/home/gkafka/maus/third_party/install/lib//libX11.so: undefined reference to `NXTransReadVector'
/home/gkafka/maus/third_party/install/lib//libX11.so: undefined reference to `NXTransRunning'
/home/gkafka/maus/third_party/install/lib//libX11.so: undefined reference to `NXTransExecute'
/home/gkafka/maus/third_party/install/lib//libX11.so: undefined reference to `_NXDisplayWriteFunction'
/home/gkafka/maus/third_party/install/lib//libX11.so: undefined reference to `_NXLostSequenceFunction'
/home/gkafka/maus/third_party/install/lib//libX11.so: undefined reference to `NXTransRead'
/home/gkafka/maus/third_party/install/lib//libX11.so: undefined reference to `NXTransWriteVector'
/home/gkafka/maus/third_party/install/lib//libX11.so: undefined reference to `NXTransExit'
/home/gkafka/maus/third_party/install/lib//libX11.so: undefined reference to `NXTransAgent'
/home/gkafka/maus/third_party/install/lib//libX11.so: undefined reference to `_NXDisplayBlockFunction'
collect2: ld returned 1 exit status
make: *** [bin/root] Error 1
FAIL: Failed to configure/make
WARNING: MAUS already setup
./install_build_test.bash: line 76: scons: command not found
./install_build_test.bash: line 80: scons: command not found
FAIL! See logs.x
Your current directory is:
/home/gkafka/maus

Your MAUS_ROOT_DIR is:
/home/gkafka/maus

These should agree
python: can't open file '/home/gkafka/maus/third_party/install/bin/nosetests': [Errno 2] No such file or directory
FAIL!  See logs.

Subtasks

Feature #1013: Find XCompRejectedRogers, Chris12 June 2012

Actions
#1

Updated by Rogers, Chris over 10 years ago

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

#2

Updated by Rogers, Chris over 10 years ago

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

#3

Updated by Kafka, Gene over 10 years ago

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

#4

Updated by Rogers, Chris over 10 years ago

What linux?

#5

Updated by Kafka, Gene over 10 years ago

Linux version 2.6.18-194.26.1.el5 () (gcc version 4.1.2 20080704 (Red Hat 4.1.2-48))

#6

Updated by Rogers, Chris over 10 years ago

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?

#7

Updated by Rajaram, Durga over 10 years ago

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

#8

Updated by Kafka, Gene over 10 years ago

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.

#9

Updated by Rogers, Chris over 10 years ago

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?

#10

Updated by Rajaram, Durga over 10 years ago

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

#11

Updated by Rogers, Chris over 10 years ago

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...

#12

Updated by Rogers, Chris over 10 years ago

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.

#13

Updated by Rogers, Chris over 10 years ago

  • Status changed from Open to Closed
  • % Done changed from 0 to 100

Also available in: Atom PDF