Bug #2651
closedBuild error in core/logger.cpp: PRIdLEAST64 is incompatible with microseconds::rep
0%
Description
Environment:
- Ubuntu 14.04.2 LTS
 - Linux kernel 3.13.0-46-generic x86_64
 - Boost 1.54
 - gcc 4.8.2
 
Build error:
../core/logger.cpp: In static member function ‘static const char* nfd::Logger::now()’:
../core/logger.cpp:61:3: error: static assertion failed: PRIdLEAST64 is incompatible with microseconds::rep
   static_assert(std::is_same<microseconds::rep, int_least64_t>::value,
   ^
../core/logger.cpp:67:47: warning: format ‘%ld’ expects argument of type ‘long int’, but argument 4 has type ‘boost::chrono::duration<long long int, boost::ratio<1ll, 1000000ll> >::rep {aka long long int}’ [-Wformat=]
            microsecondsSinceEpoch % ONE_SECOND);
                                               ^
../core/logger.cpp:67:47: warning: format ‘%ld’ expects argument of type ‘long int’, but argument 5 has type ‘boost::chrono::duration<long long int, boost::ratio<1ll, 1000000ll> >::rep {aka long long int}’ [-Wformat=]
../core/logger.cpp:67:47: warning: format ‘%ld’ expects argument of type ‘long int’, but argument 4 has type ‘boost::chrono::duration<long long int, boost::ratio<1ll, 1000000ll> >::rep {aka long long int}’ [-Wformat=]
../core/logger.cpp:67:47: warning: format ‘%ld’ expects argument of type ‘long int’, but argument 5 has type ‘boost::chrono::duration<long long int, boost::ratio<1ll, 1000000ll> >::rep {aka long long int}’ [-Wformat=]
This Bug is originally reported on ndn-interest by Anil Jangam.
Files
      
      Updated by Junxiao Shi over 10 years ago
      
    
    - Assignee set to Anonymous
 
The usage of PRIdLEAST64 was introduced by @Steve in commit:3a61fb4758f4250b2fccd9960f00a2cda67fb76a.
Please have a look, and confirm whether this platform has different types in microseconds::rep vs int_least64_t.
      
      Updated by Anonymous over 10 years ago
      
    
    - Assignee deleted (
Anonymous) 
Sorry, but I don't have time to track this down. Please reassign to someone else.
I cannot reproduce this problem on my 14.04 VM (tried the 0.3.1 NFD/cxx tags and HEADs 76c751ce80109cd429cd45d32a04015f7715546b 895395f7f666445712171bb7b7e82387682b3c84).
- Linux ubuntu 3.16.0-31-generic #41~14.04.1-Ubuntu SMP Wed Feb 11 19:30:13 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux
 - gcc (Ubuntu 4.8.2-19ubuntu1) 4.8.2
 - boost 1.54
 
Updated the VM, still works:
- Linux ubuntu 3.16.0-31-generic #43~14.04.1-Ubuntu SMP Tue Mar 10 20:13:38 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux
 
      
      Updated by Davide Pesavento over 10 years ago
      
    
    Junxiao can you reproduce this?
It doesn't make much sense to me. On 64 bit platforms, long int and long long int are both 64 bits in size. Maybe you're building with -m32? Are you sure it's really boost 1.54? Can we see a full configure+build log?
Why are we asserting anyway? (as opposed to always casting to a wider type)
      
      Updated by Junxiao Shi over 10 years ago
      
    
    I didn't attempt to reproduce this.
@Steve suggested to assume PRIdLEAST64 to "avoid a cast".
I added the assertion in order to enforce the type is correct.
@Anil, please post here:
- your 
./waf configureline - the complete output from 
./waf configure build/config.logfile- the complete output from 
./waf 
(note: @Anil isn't watching this issue using Redmine feature, but he/she agreed to watch this issue manually)
      
      Updated by Davide Pesavento over 10 years ago
      
    
    Junxiao Shi wrote:
- the complete output from
 ./waf
./waf output is utterly unhelpful by default. Please post the output of ./waf -v instead.
      
      Updated by Anil Jangam over 10 years ago
      
    
    - File waf_configure.txt waf_configure.txt added
 - File config.log config.log added
 - File waf_v.txt waf_v.txt added
 
Attaching all the logs as requested.
      
      Updated by Davide Pesavento over 10 years ago
      
    
    Are you sure you don't have an old version of boost in /usr/local/include?
      
      Updated by Anil Jangam over 10 years ago
      
    
    - File boost_package.txt boost_package.txt added
 
The ./waf configure is picking up the correct version, which is = "Checking boost includes : 1.54.0."
I also checked the installed boost packages and it does not show any other version than 1.54. See attached file: boost_package.txt.
Also my /usr/local/include listing is as below.
ndnusr1@ndnhost1:~/sandbox/NLSR$ ls -l /usr/local/include/
total 28
drwxr-xr-x 93 root root 12288 Jun 25  2014 boost
drwxr-xr-x  2 root root  4096 Feb 25 16:51 ChronoSync
drwxr-xr-x 11 root root  4096 Nov 25 17:23 mongo
drwxr-xr-x  8 root root  4096 Feb 25 15:39 ndn-cxx
drwxr-xr-x  3 root root  4096 Jun 24  2014 ns3-dev
Let me know if you need any other data.
      
      Updated by Davide Pesavento over 10 years ago
      
    
    Anil Jangam wrote:
ndnusr1@ndnhost1:~/sandbox/NLSR$ ls -l /usr/local/include/
total 28
drwxr-xr-x 93 root root 12288 Jun 25 2014 boost
drwxr-xr-x 2 root root 4096 Feb 25 16:51 ChronoSync
drwxr-xr-x 11 root root 4096 Nov 25 17:23 mongo
drwxr-xr-x 8 root root 4096 Feb 25 15:39 ndn-cxx
drwxr-xr-x 3 root root 4096 Jun 24 2014 ns3-dev
I see a boost folder there... what is it?
Rename it to something else and retry building NFD please.
      
      Updated by Anil Jangam over 10 years ago
      
    
    After removing/renaming boost folder in /usr/local/include, I could compile the NFD successfully. This is a non-issue now. I was thinking that /usr/local/include was containing 1.54.0 version of boost.
/anil.
      
      Updated by Junxiao Shi over 10 years ago
      
    
    - Status changed from New to Rejected
 
Dirty environment problem, see note-10.