Problems with 5.34/01?

ROOT
1

I just finished building root 5.34/01 (the “recommended” version). A few things that used to work before now break.

First of all, the root “greeting header” is saying strange things:

5.22?? Even though we have tags/v5-34-01? My ROOTSYS is pointing to the right place.

But then I get major problems when I try to do vector operations. Here’s the output:

root [0] #include <vector>   
root [1] std::vector<TH2F*> a
Error: link requested for unknown class vector<TH2F*>::.* /home/aregjan/code/root/read/scripts/AutoDict_vector_TH2F__.cxx:7:
Warning: Error occurred during reading source files
Warning: Error occurred during dictionary source generation
!!!Removing /home/aregjan/code/root/read/scripts/AutoDict_vector_TH2F___cxx_ACLiC_dict.cxx /home/aregjan/code/root/read/scripts/AutoDict_vector_TH2F___cxx_ACLiC_dict.h !!!
Error: /usr/local/farm/root_v5.34.01/bin/rootcint: error loading headers...
Error in <ACLiC>: Dictionary generation failed!
...more stuff deleted...
2

(It seems to me that your ROOT setup is screwed -> you have a mix of 5.22 and 5.34.)
See: [url]libRIO.so error

Also try to “rm -f AutoDict_vector_*”

See also [url]Release 5.32.03 on Ubuntu 12.04 and [url]Release 5.32.03 on Ubuntu 12.04

3

You mean you want me to run thisroot.csh? No difference, here’s the result –

4

And, just to be completely clear:

5

Try (check “Root.DynamicPath”, “Root.MacroPath”, “Root.PluginPath”):
root [0] gEnv->Print()
and:
root-config --version
root-config --prefix
root-config --etcdir
and (if “which” doesn’t work, try “type” instead):
which root
which root.exe
which rootn.exe
ldd ${ROOTSYS}/bin/root.exe
ldd ${ROOTSYS}/bin/rootn.exe

6

Ok, here’s the output for gEnv->Print():

And here’s the rest:

7

To me it looks like the executables were coming from 5.22 while (some?) libraries from 5.34.
Moreover, you seem to have a 64-bit system (x86_64) but your ROOT is compiled as a 32-bit application.

I would like to propose that you destroy your installation completely using:
rm -rf /usr/local/farm/root_v5.34.01
and then install everything from scratch using the procedure from (just replace “v5-32-00-patches” with “v5-34-00-patches” and “/opt/ROOT/v5-32-00-patches” with “/usr/local/farm/v5-34-00-patches”):
[url]Release 5.32.03 on Ubuntu 12.04

8

Pepe le Pew, nowhere in my diagnostics – with the exception of the login banner – do I see any mention of 5.22.

Also, my /usr/lib is actually 64-bit (in case if that’s what makes you think that this is a 32bit build).

Anyway, I’ll try your suggestion tonight and report on the results.

p.s. Btw, I also installed 5.32.04, and everything is working flawlessly. Eh…

9

Usually there should be a difference between /lib and /lib64 and between /usr/lib and /usr/lib64 (the same names of libraries inside but compiled and linked for different “architectures”).
But now I see “linuxx8664gcc” in your output …
Anyhow, you can also try:
root-config --arch

Just to make it clear … [code][…]$ root

  •                                     *

  •    W E L C O M E  to  R O O T       *

  •                                     *
  • Version 5.34/01 13 July 2012 *
  •                                     *
  • You are welcome to visit our Web site *
  •      http://root.cern.ch            *

  •                                     *

ROOT 5.34/01 (branches/v5-34-00-patches@45034, Aug 25 2012, 22:04:00 on linuxx8664gcc)

CINT/ROOT C/C++ Interpreter version 5.18.00, July 2, 2010
Type ? for help. Commands must be C++ statements.
Enclose multiple statements between { }.
root [0] #include
root [1] std::vector<TH2F*> a
root [2] .q
[…]$ ls AutoDict_vector_TH2F__*
AutoDict_vector_TH2F__.cxx AutoDict_vector_TH2F___cxx.so
AutoDict_vector_TH2F___cxx.d[/code]

10

In my directory structure my /usr/lib64 is simply a link to /usr/lib, while /usr/lib32 is a separate dir. Same with /lib, it’s being pointed at by /lib64.

11

Hi,

it looks like you are linking with on old TRint.o file, the one that prints the banner. The old values come from inline TROOT functions, while the correct ones come from TROOT function calls (which seems to be correct).

Can you just rebuild your ROOT version as Pepe suggests, doing:

cd root
./configure
make
bin/thisroot.sh
root.exe

Cheers, Fons.

12

Ok, I think I know what’s happening. I was always under the impression that the build is successful, yet it wasn’t – it just didn’t complain. I checked the binary $ROOTSYS/bin/root – it was an old binary that came with the tarball.

So far I have been trying to build with

>make -j 2

for a dual core processor, and I didn’t have any errors – hence the confusion. But now I did

>make

and the errors are finally pouring out:

13

Can it be that you have again unpacked several tarballs into your working subdirectory and you then try to build ROOT in the same subdirectory from the source code?
Or maybe you tried to build ROOT for different architectures without making “distclean” in-between?
If yes, first make sure that you delete the source code and the “target” subdirectories completely. Then unpack the source code and then configure and make ROOT.

14

Here’s what I did. I removed the 5.34.01 directory, re-downloaded the tarball and unpacked it, configured it,
and ran

>make

(no dual core support this time).

And it all worked fine! It went through a lengthy build, gave me the final banner confirming that the build was successful, and after I run “root” everything worked correctly – the banner had 5.34.01.

However, I then deleted the 5.34.01 directory again, and this time I tried

>make -j 2

It compiled everything until the following line:

and got stuck there. It has been stuck there for the last 2 hours. CPU at 100%, and no progress.

UPDATE: I Control-C-ed the build, but noticed that bin/root was already built. Tried it – it works! Hmm…maybe that’s some bug in the Makefile?

15

[quote]UPDATE: I Control-C-ed the build, but noticed that bin/root was already built. Tried it – it works! Hmm…maybe that’s some bug in the Makefile?[/quote]Yes, there seems to be a bug in Makefile and/or make that leads to this issue. We have not been able to reproduce it frequently enough to track it down.

Philippe.