Re: [DynInst_API:] Compile issue building Dyninst on ORNL titan

[Jim Galarowicz <jeg@xxxxxxxxxxxxx>]

Hi Josh,

Thanks for the reply.  I haven't been able to figure anything out. This 
must be unique to Titan?   It seems no one else has had this issue?
I tried looking along the include path.

 39%] Building CXX object 
dyninstAPI/CMakeFiles/dyninstAPI.dir/src/BPatch.C.o
In file included from 
/ccs/home/jgalaro/OpenSpeedShop_ROOT/BUILD/titan-ext1/dyninst-8.2.0/common/src/headers.h:53:0,
                 from 
/ccs/home/jgalaro/OpenSpeedShop_ROOT/BUILD/titan-ext1/dyninst-8.2.0/common/src/Timer.h:43,
                 from 
/ccs/home/jgalaro/OpenSpeedShop_ROOT/BUILD/titan-ext1/dyninst-8.2.0/common/src/stats.h:38,
                 from 
/ccs/home/jgalaro/OpenSpeedShop_ROOT/BUILD/titan-ext1/dyninst-8.2.0/dyninstAPI/src/BPatch.C:43:
/ccs/home/jgalaro/OpenSpeedShop_ROOT/BUILD/titan-ext1/dyninst-8.2.0/common/src/fraction.h: 
In constructor 'fraction::fraction(int64_t)':
/ccs/home/jgalaro/OpenSpeedShop_ROOT/BUILD/titan-ext1/dyninst-8.2.0/common/src/Types.h:140:28: 
error: 'INT64_C' was not declared in this scope
 #define I64_C(x)  INT64_C(x)
                            ^
/ccs/home/jgalaro/OpenSpeedShop_ROOT/BUILD/titan-ext1/dyninst-8.2.0/common/src/fraction.h:59:50: 
note: in expansion of macro 'I64_C'
   explicit fraction(int64_t n) : numer(n), denom(I64_C(1))  {

I didn't see any includes of stdint.h in the include trace above when I 
examined each of the files.
jgalaro@titan-ext1:~/OpenSpeedShop_ROOT/BUILD/titan-ext1/dyninst-8.2.0/common/src> 
grep stdint *.h
Types.h:#include <stdint.h>
Types.h:#include <stdint.h>
Types.h:#include <stdint.h>
Types.h:#include <stdint.h>
jgalaro@titan-ext1:~/OpenSpeedShop_ROOT/BUILD/titan-ext1/dyninst-8.2.0/common/src> 
cd ../../dyninstAPI/src
jgalaro@titan-ext1:~/OpenSpeedShop_ROOT/BUILD/titan-ext1/dyninst-8.2.0/dyninstAPI/src> 
!gre
grep stdint *.h

I'm dead in the water on Titan.    I've built Dyninst here many times.  
I tried the pre-release 8.2 version I had and that fails in the same way.
They have upgraded the system since then.

I'll try again tomorrow.

Thanks,
Jim G

On 10/17/2014 02:58 PM, Josh Stone wrote:
> On 10/17/2014 02:25 PM, Jim Galarowicz wrote:
> > I'm not sure if the patchAPI compile options have the correct defines
> > set or is there a compile option that is required to get the constants
> > recognized?
> > I put the #include stdint.h into BPatch.C to see if the Dyninst build
> > was missing including stdint.h because it is enclosed in some if
> > <defined> type code.
> > So, I'm guessing there is an missing option or missing compiler define
> > that is needed.
> >
> >   From stdint.h on Titan:
> >
> > /* The ISO C99 standard specifies that in C++ implementations these
> >      macros should only be defined if explicitly requested.  */
> > #if !defined __cplusplus || defined __STDC_LIMIT_MACROS
> Yet common/src/Types.h ensures __STDC_LIMIT_MACROS is defined in every
> case before including stdint.h.
>
> I would guess there's a problem in the #include order.  As in, something
> that precedes Types.h is indirectly including stdint.h, when
> __STDC_LIMIT_MACROS isn't defined yet.  Then when Types.h gets around to
> it, the _STDINT_H guards are already set, so it does nothing.