ROOT 5.16.00: cannot open file "libRint.so"

ROOT
#1

Hello,

I’ve noticed a peculiar problem with the latest production version of ROOT, compiled by me under Linux from sources - on two different architectures, i.e. x86 and amd64. ROOT builds and installs fine, but whenever I run it I get the following messages:

$ root
Error: cannot open file "libRint.so"  :0:
Error: cannot open file "libRint.so"  :0:
*** Interpreter error recovered ***
  *******************************************
  *                                         *
  *        W E L C O M E  to  R O O T       *
  *                                         *
  *   Version   5.16/00      27 June 2007   *
  *                                         *
  *  You are welcome to visit our Web site  *
  *          http://root.cern.ch            *
  *                                         *
  *******************************************

Compiled on 13 July 2007 for linuxx8664gcc with thread support.

CINT/ROOT C/C++ Interpreter version 5.16.21, June 22, 2007
Type ? for help. Commands must be C++ statements.
Enclose multiple statements between { }.
root [0]

As a result of the error ROOT doesn’t parse my rootlogon file, but otherwise everything appears to work as it should.

I have run strace on the root executable and while I couldn’t figure out what exactly causes the problem, I have noticed that for some reason libRint.so is looked for in include directories instead of lib. Indeed, creating a symlink to /opt/root/lib/libRint.so in /opt/root/include makes the problem go away.

Please let me know if you need any more information to help you get rid of this problem.

–
MS

#2

Hi,
could you post the content of config.status, config/Makefile.config, and the values of $ROOTSYS and $LD_LIBRARY_PATH?
Axel.

#3

Unfortunately the source tree was already gone when I read your request and only yesterday did I manage to get to rebuilding ROOT. Interestingly enough, the problem is gone in the rebuilt version (on x86 at least, I have yet to try the amd64 box)! I suspect this must have been some glitch caused by running make in concurrent mode, as I normally use something around -j3.