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

[Dave Goodell <davidjgoodell@xxxxxxxxx>]

> On Oct 18, 2014, at 12:17 AM, Josh Stone <jistone@xxxxxxxxxx> wrote:
> 
>> On 10/17/2014 08:17 PM, Jim Galarowicz wrote:
>> 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.
> 
> It's not even just that direct include chain that you have to worry
> about, but also anything each those may have included before getting to
> this point, or even what BPatch.C included before that line 43.
> 
>> 
>> 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.
> 
> Something as innocent as a glibc or libstdc++ update may have altered
> what headers you're pulling indirectly.  It can be nasty to figure this
> out, no doubt.
> 
> In fact, current glibc no longer bothers with __STDC_LIMIT_MACROS:
> https://sourceware.org/bugzilla/show_bug.cgi?id=15366
> 
>> I'll try again tomorrow.
> 
> Perhaps peek through the preprocessed output?  Run "make VERBOSE=1" to
> get the failed command, then replace "-c" with "-E" to get just the
> preprocessor result, and see where it went awry.

(Sorry for not trimming, replying from my phone)

Also adding "-dD" will show you what got #defined where. It usually makes a big difference for me when I'm debugging a preprocessing problem. 

-Dave

> Or if you're willing to kludge, just toss "#define __STDC_LIMIT_MACROS"
> at the beginning of BPatch.C.  That will at least get you unstuck. :)
> _______________________________________________
> Dyninst-api mailing list
> Dyninst-api@xxxxxxxxxxx
> https://lists.cs.wisc.edu/mailman/listinfo/dyninst-api