Bug #2743: error: 'to_string' is not a member of 'std' when cross-compiling NFD for OpenWRT - NFD - NDN project issue tracking system

Actions

Copy link

Bug #2743

closed

error: 'to_string' is not a member of 'std' when cross-compiling NFD for OpenWRT

Added by Mathias Gibbens over 9 years ago. Updated over 9 years ago.

Status:

Closed

Priority:

Normal

Assignee:

Alex Afanasyev

Category:

Build

Target version:

Unsupported

Start date:

04/10/2015

Due date:

% Done:

100%

Estimated time:

Description

Today I was working on cross-compiling NFD 0.3.1 for OpenWRT. When I do, I get this error (after fixing a different issue reported in bug #2299):

../tools/ndn-autoconfig/base-dns.cpp: In member function 'std::string ndn::tools::autoconfig::BaseDns::parseSrvRr(const ndn::tools::autoconfig::BaseDns::QueryAnswer&, int)':
../tools/ndn-autoconfig/base-dns.cpp:163:14: error: 'to_string' is not a member of 'std'
   uri.append(std::to_string(convertedPort));

I found a similar issue in another project at https://bitbucket.org/fenics-project/dolfin/commits/066b8cfe, and changing std::to_string to boost::lexical_cast<std::string> seems to fix the problem.

Opinions?

Related issues 1 (0 open — 1 closed)

Actions

Copy link

Updated by Davide Pesavento over 9 years ago

Target version set to Unsupported

This appears to be related to uClibc, the C library used by OpenWRT. See also https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58393

Actions

Copy link

Updated by Mathias Gibbens over 9 years ago

This also affects ./rib/fib-updater.cpp in NFD's master branch.

While waiting for uClibc to be updated, would there be any issues stopping us from switching to the boost function? NFD is already pulling in those libraries so there wouldn't be any extra dependencies and doing so would help ensure that the NFD code compiles nicely in many different environments.

Actions

Copy link

Updated by Alex Afanasyev over 9 years ago

In many places, I personally tried to reduce use of boost::lexical_cast, as it is suppose to be slower than to_string. I would suggest that we better add an emulation of to_string specifically for uClibc platform (and may be some others).

Actions

Copy link

Updated by Junxiao Shi over 9 years ago

I would suggest that we better add an emulation of to_string specifically for uClibc platform (and may be some others).

It's unnecessary to use platform-specific emulation.

Instead, detect this feature in .waf-tools/compiler-features.py, and fallback to boost::lexical_cast<std::string> if std::to_string isn't detected.

Actions

Copy link

Updated by Alex Afanasyev over 9 years ago

I disagree with this. Having dependent code (I'm assuming you're suggesting ifdefs all over the place) makes implementation cumbersome...

So. Either we do emulation, figure out flags to allow gcc on these platforms to expose to_string, or fall back to lexical_cast (this would be my last resort).

Actions

Copy link

Updated by Alex Afanasyev over 9 years ago

@Mathias. We have to_string in a few other places. All of them cause the error or the compilation simply stopped at the first error?

Actions

Copy link

Updated by Junxiao Shi over 9 years ago

I'm assuming you're suggesting ifdefs all over the place

You misunderstood note-4.

#ifdef appears only in common.hpp, which enables:

namespace std {

template<typename V>
std::string
to_string(const V& v)
{
  return boost::lexical_cast<std::string>(v);
}

} // namespace std

The point is, emulation is enabled as a result of feature detection, not as a result of library version detection.

Actions

Copy link

Updated by Mathias Gibbens over 9 years ago

@Alex, I did a grep to find where ever std::to_string was used in the NFD code. In the current master there are only two occurrences. The build stops at the first one, but either of them will cause the error.

@Junxiao, I like your proposed solution.

Actions

Copy link