Compile ROOT on Linux with PPC and xlC IBM compiler

ROOT
1

Hi ROOT experts,
I’m trying to install ROOT at SARA computing center:

subtrac.sara.nl/userdoc/wiki/hu … escription

They have a wonderful cluster with 32 cores per node…
The plan is to do some work for multi-threading.

The problem comes at beginning: the ROOT compilation.
I downloaded the 5.26.00 source code version using SVN and I found that there is not a makefile for compiling ROOT with Linux on PPC and xlC.
Following a suggestion by Fons, I tried to write my own makefile for this case (linuxppc64xlc). I took as example the two makefiles (inside the directory config):

Makefile.aix5
Makefile.macosxxlc
and I put my make file inside the directory config.
Then I added the architecture inside the file config/ARCHS.

You can find the new Makefile at: idefix.mi.infn.it/~lazzaro/misc/ … uxppc64xlc

Doing so the configure command works.
The log is: idefix.mi.infn.it/~lazzaro/misc/configure.log

So I started the compilation with make.
The log is:

First problem is that I get this warning:

xlC_r: 1501-210 (W) command option t contains an incorrect subargument

This is due to the -pthread option.
The library should be on xlC -lpthread for the linking and then there is not needed to have this option (if I understood correctly) when we use xlC_r commands. How can I remove this option?
Anyway, this is a warning…

The problem happens at the end, doing this command:

xlC_r -O -qpic -q64 -qchar=signed -qstrict -qarch=auto -qtune=auto -DG__ANSI -DG__REGEXP -Iinclude -D_POSIX2_SOURCE -DG__P2FCAST -DG__SHAREDLIB -DG__ROOT -DG__REDIRECTIO -DG__OSFDLL -DG__NEWSTDHEADER -DG__HAVE_CONFIG -DG__NOMAKEINFO -DG__CINTBODY -Icint/cint/inc -Icint/cint/src -Icint/cint/src/dict -pthread -Icint/cint/lib/libstrm -Icint/cint/lib/stream -I. -o cint/cint/src/dict/libstrm.o -c cint/cint/src/dict/libstrm.cxx

with this error:

“cint/cint/lib/stream/iostrm.h”, line 36.18: 1540-0040 (S) The text “" is unexpected. “streambuf” may be undeclared or ambiguous.
“cint/cint/lib/stream/iostrm.h”, line 37.18: 1540-0040 (S) The text "” is unexpected. “streambuf” may be undeclared or ambiguous.
“cint/cint/lib/stream/iostrm.h”, line 38.18: 1540-0040 (S) The text “" is unexpected. “streambuf” may be undeclared or ambiguous.
“cint/cint/lib/stream/iostrm.h”, line 39.18: 1540-0040 (S) The text "” is unexpected. “ofstream” may be undeclared or ambiguous.
“cint/cint/lib/stream/iostrm.h”, line 40.18: 1540-0040 (S) The text “" is unexpected. “ofstream” may be undeclared or ambiguous.
“cint/cint/lib/stream/iostrm.h”, line 41.18: 1540-0040 (S) The text "” is unexpected. “ifstream” may be undeclared or ambiguous.

After few investigations, it turns out it needs to include the namespace for those classes inside cint/cint/lib/stream/iostrm.h.
Adding:

using namespace std;

eliminates the problem.
But then a similar problem happens for cint/cint/src/dict/libstrm.cxx.
Actually with this file the situation is worse, since it doesn’t recognize a lot of standard classes (for example in the line

typedef fstreambase G__Tfstreambase;

gives this error:

The text “G__Tfstreambase” is unexpected. “fstreambase” may be undeclared or ambiguous.

even if I add the include and the namespace std:

#include
using namespace std;

)

Any kind of suggestion is highly appreciate…

Thanks,

Alfio

2

Hi,

we’ll need to port the CINT STL dictionaries to your platform. Let’s start with something that should resemble what you use. In cint/cint/Module.mk you will find the line
ifeq ($(CXXCMD),xlC)
ifeq ($(PLATFORM),macosx)

Add a new case for your platform, but instead of gcc3strm.cxx (like for macosx) try immediately with gcc4strm. If that fails try with gcc3strm. Let us know what the output is; I would appreciate a full log attached instead of just the relevant snippets.

Cheers, Axel.

3

Hi Axel,
thanks for you answer. Indeed we are doing progress…
I have slightly changed the makefile for the configuration (new version at idefix.mi.infn.it/~lazzaro/misc/ … uxppc64xlc) and I added these lines in cint/cint/Module.mk:

ifeq ($(CXXCMD),xlC_r)
ifeq ($(PLATFORM),linux)
CINTS2 := $(filter-out $(MODDIRSD)/libstrm.%,$(CINTS2))
CINTS2 := $(filter-out $(MODDIRSD)/longif.%,$(CINTS2))
CINTS2 += $(MODDIRSD)/gcc4strm.cxxCINTS2 += $(MODDIRSD)/longif3.cxxendifendif

It gives an error in the compilation, but at least now the error is different from the previous one (and I think more reasonable):

Making cint/iosenum/iosenum.linuxppc64xlc…
/bin/sh: line 6: 23381 Segmentation fault cint/cint/main/cint_tmp -Icint/cint/include -Icint/cint/stl -Icint/cint/lib -Iinclude cint/io
senum/iosenum.cxx > /dev/null
mv: cannot stat `iosenum.h’: No such file or directory

The full log is:
idefix.mi.infn.it/~lazzaro/misc/make_axel.log

Using the gcc3strm.cxx gives this errors, much before the case with gcc4strm.cxx:

“cint/cint/src/dict/gcc3strm.cxx”, line 311.79: 1540-0217 (S) “operator==” is not a member of “class fpos<__mbstate_t>”.
“cint/cint/src/dict/gcc3strm.cxx”, line 317.79: 1540-0217 (S) “operator!=” is not a member of “class fpos<__mbstate_t>”.

So I assume that the case gcc4strm.cxx goes in the right direction…

Any other suggestions?
Thanks!

Alfio

[quote=“Axel”]Hi,

we’ll need to port the CINT STL dictionaries to your platform. Let’s start with something that should resemble what you use. In cint/cint/Module.mk you will find the line
ifeq ($(CXXCMD),xlC)
ifeq ($(PLATFORM),macosx)

Add a new case for your platform, but instead of gcc3strm.cxx (like for macosx) try immediately with gcc4strm. If that fails try with gcc3strm. Let us know what the output is; I would appreciate a full log attached instead of just the relevant snippets.

Cheers, Axel.[/quote]

4

Ok, the offending command is:

cint/cint/main/cint_tmp

Recompiling with --build=debug and running it on gdb, I get:

Program received signal SIGSEGV, Segmentation fault.
0x000000001029d4b4 in G__tovalue (p=
{obj = {d = 0, i = 0, reftype = {i = 0, reftype = 0}, ch = 0 ‘\0’, sh = 0, in = 0, fl = 0, uch = 0 ‘\0’, ush = 0, uin = 0, ulo = 0, ll = 0, ull = 0, ld = }, ref = 0, type = 73, tagnum = -1, typenum = -1, isconst = 0 ‘\0’, dummyForCint7 = {fTypeName = 0x400, fModifiers = 1024}}) at cint/cint/src/value.cxx:413
413 result.obj.in = (*(int *)(p.obj.i));

(gdb) where
#0 0x000000001029d4b4 in G__tovalue (p=
{obj = {d = 0, i = 0, reftype = {i = 0, reftype = 0}, ch = 0 ‘\0’, sh = 0, in = 0, fl = 0, uch = 0 ‘\0’, ush = 0, uin = 0, ulo = 0, ll = 0, ull = 0, ld = }, ref = 0, type = 73, tagnum = -1, typenum = -1, isconst = 0 ‘\0’, dummyForCint7 = {fTypeName = 0x400, fModifiers = 1024}}) at cint/cint/src/value.cxx:413
#1 0x00000000100f05c0 in G__getexpr (expression=0x10996bb0 “(int)(272550552)”) at cint/cint/src/expr.cxx:1464
#2 0x00000000100cb844 in G__define_var (tagnum=-1, typenum=-1) at cint/cint/src/decl.cxx:2506
#3 0x00000000101bdcdc in G__exec_statement (mparen=0xffffffe91f0) at cint/cint/src/parse.cxx:5690
Dwarf Error: Cannot find DIE at 0xe7c8b referenced from DIE at 0xe845a [in module /gpfs/h05/hpc_0285/packages/root-5.26.00.src/cint/cint/main/cint_tmp]

I’m missing some compilation options…

Alfio

5

Hi Alfio,

yikes, looks like CINT converts “(int)(272550552)” to (int)0. I’ll check on Monday on our local PPC; it might be a byte order issue.

Cheers, Axel.

6

Hi Alfio,

the conversion works for me on the powerpc machine I have access to. It’s 32bit, which might explain the difference. But it could also be that your CINT build is not configured correctly.

Could you check whether ppc or PPC gets defined by xlC? Or even better: could I get temporary access to the machine and debug myself (if yes, please contact me via private email)? I have a NIKHEF account if that helps.

Cheers, Axel.