Compiling errors with 'root-config'

ROOT
1

I’m trying to compile a macro with g++ using the command:

and get the following error:

[quote]g++: root-config --cflags: No such file or directory
g++: root-config --glibs: No such file or directory [/quote]

i’ve tried just typing root-config --glibs etc… and it works just fine. i also tried manually entering the linked libraries into a make file, but i just get errors of the form:

etc…

for each ROOT header that i’ve included. If i try compiling in root, using:

then i get a segmentation fault. my guess for this is because i’m loading a large root file (1.5 Gig)? but the script runs just fine if i run it normally through root. it just takes forever. Please help!! thanks,

Michael

I’m running Ubuntu 8.04 (hardy)
Root 5.18/00
g++ 4.2.3

2

Instead of g++ 'root-config --cflags' myMacro.c 'root-config --glibs'
use g++ `root-config --cflags` myMacro.c `root-config --glibs`
Note the (subtle) difference: you need to use back-tick instead of forward tick.

[quote]then i get a segmentation fault. [/quote]Humm … could be many many things … What is the stack trace? Did you try valgrind? (by running “valgrind root.exe” to start root)

Cheers,
Philippe.[/quote]

3

the backward tics did it. but i’m getting the seg fault still.

here’s what it gives me:

[quote]root [0] .x SStreams.c+
==7202==
==7202== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 47 from 1)
–7202–
–7202-- supp: 47 dl-hack3-1
==7202== malloc/free: in use at exit: 0 bytes in 0 blocks.
==7202== malloc/free: 1,481 allocs, 1,481 frees, 780,549 bytes allocated.
==7202==
==7202== All heap blocks were freed – no leaks are possible.
–7202-- memcheck: sanity checks: 70 cheap, 4 expensive
–7202-- memcheck: auxmaps: 0 auxmap entries (0k, 0M) in use
–7202-- memcheck: auxmaps_L1: 0 searches, 0 cmps, ratio 0:10
–7202-- memcheck: auxmaps_L2: 0 searches, 0 nodes
–7202-- memcheck: SMs: n_issued = 38 (608k, 0M)
–7202-- memcheck: SMs: n_deissued = 8 (128k, 0M)
–7202-- memcheck: SMs: max_noaccess = 65535 (1048560k, 1023M)
–7202-- memcheck: SMs: max_undefined = 8 (128k, 0M)
–7202-- memcheck: SMs: max_defined = 61 (976k, 0M)
–7202-- memcheck: SMs: max_non_DSM = 35 (560k, 0M)
–7202-- memcheck: max sec V bit nodes: 2 (0k, 0M)
–7202-- memcheck: set_sec_vbits8 calls: 6 (new: 2, updates: 4)
–7202-- memcheck: max shadow mem size: 864k, 0M
–7202-- translate: fast SP updates identified: 6,389 ( 90.5%)
–7202-- translate: generic_known SP updates identified: 424 ( 6.0%)
–7202-- translate: generic_unknown SP updates identified: 245 ( 3.4%)
–7202-- tt/tc: 11,821 tt lookups requiring 12,217 probes
–7202-- tt/tc: 11,821 fast-cache updates, 2 flushes
–7202-- transtab: new 5,476 (112,905 -> 1,632,255; ratio 144:10) [0 scs]
–7202-- transtab: dumped 0 (0 -> ??)
–7202-- transtab: discarded 0 (0 -> ??)
–7202-- scheduler: 7,005,153 jumps (bb entries).
–7202-- scheduler: 70/11,240 major/minor sched events.
–7202-- sanity: 71 cheap, 4 expensive checks.
–7202-- exectx: 769 lists, 206 contexts (avg 0 per list)
–7202-- exectx: 3,009 searches, 2,832 full compares (941 per 1000)
–7202-- exectx: 0 cmp2, 98 cmp4, 0 cmpAll
–7202-- errormgr: 6 supplist searches, 75 comparisons during search
–7202-- errormgr: 47 errlist searches, 98 comparisons during search[/quote]

by stack trace, i assume you mean where does it fail? immediatley. it doesn’t even get to the the variable declarations. here’s how the function starts (headers ommited) it doesn’t even get to the error output.

[code]void SStreams(){

gROOT ->Reset();

cout << “error” << endl; …[/code]

4

here's how the function starts (headers ommited) it doesn't even get to the error output. Actually you do not know that for sure. cout is a ‘buffered’ output stream, which mean that the C++ library can decided when to actually print the stream to the screen. In particular, it often happens that the crash happens between the cout and the actual printing to the screen , in which case you would not see the printing eventhough it happened!.

Anyway, never use gROOT->Reset in a function, it wipes out the declaration of the function itself (amongst other things) and hence the result might be surprising.

When the segfault happens it should print a list of function call (stack) indicating where the problem appeared (alternatively you can get it by using gdb [type gdb root.exe]

Cheers,
Philippe

5

i’ve been fooling with gdb for sometime now. and i was getting a segfault message, but it wouldn’t give me a line number, it just said it was in main(). and i took out the gROOT->Reset();

i managed to get it going, then it said:

[quote]#0 0x08049c6f in main ()
(gdb) next
Single stepping until exit from function main,
which has no line number information.
root [0]
Processing SStreams.c+…

Program exited with code 013.[/quote]

this is when i run:

[quote]$gdb root[/quote] [quote]run SStreams.c+[/quote] and type ‘finish’, then next until i get to that point.

6

I believe that endl flushes the output stream in C++, so that in this case it should print if it gets to it. (I don’t know if cint would change that behavior or not).

In any case, using cerr is safer because it’s not buffered and will still print out if the error that is making it crash is in the output statement itself.

Cheers,
Charles

7

Hi,

I am not quite sure but your gdb output seen to indicate that things are now working properly, isn’t it?

Note that in order to see line number you need to compile ROOT (and your code) in debug mode (-g option on the g++ command line).

Cheers,
Philippe.

8

Hi,

and don’t run “gdb root” but “gdb root.exe” (yes, on linux).

Cheers, Axel.