Project

General

Profile

Actions

Bug #2651

closed

Build error in core/logger.cpp: PRIdLEAST64 is incompatible with microseconds::rep

Added by Junxiao Shi over 9 years ago. Updated over 9 years ago.

Status:
Rejected
Priority:
Normal
Assignee:
-
Category:
Core
Target version:
Start date:
03/16/2015
Due date:
% Done:

0%

Estimated time:

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

waf_configure.txt (1.52 KB) waf_configure.txt Anil Jangam, 03/17/2015 01:48 PM
config.log (23.9 KB) config.log Anil Jangam, 03/17/2015 01:48 PM
waf_v.txt (6.41 KB) waf_v.txt Anil Jangam, 03/17/2015 01:48 PM
boost_package.txt (3.09 KB) boost_package.txt Anil Jangam, 03/17/2015 05:58 PM
Actions #1

Updated by Junxiao Shi over 9 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.

Actions #2

Updated by Anonymous over 9 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
Actions #3

Updated by Davide Pesavento over 9 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)

Actions #4

Updated by Junxiao Shi over 9 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 configure line
  • the complete output from ./waf configure
  • build/config.log file
  • the complete output from ./waf

(note: @Anil isn't watching this issue using Redmine feature, but he/she agreed to watch this issue manually)

Actions #5

Updated by Davide Pesavento over 9 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 9 years ago

Attaching all the logs as requested.

Actions #7

Updated by Davide Pesavento over 9 years ago

Are you sure you don't have an old version of boost in /usr/local/include?

Actions #8

Updated by Anil Jangam over 9 years ago

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.

Actions #9

Updated by Davide Pesavento over 9 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.

Actions #10

Updated by Anil Jangam over 9 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.

Actions #11

Updated by Junxiao Shi over 9 years ago

  • Status changed from New to Rejected

Dirty environment problem, see note-10.

Actions

Also available in: Atom PDF