OpenWrt Forum Archive

Topic: ambiguous overload for 'operator<<' with C++ package

The content of this topic has been archived on 17 Apr 2018. There are no obvious gaps in this topic, but there may still be some posts missing at the end.

Last night, I updated my local OpenWRT git trunk to the commit ee2edac3056bdd8ba185377c56b88c905b7c87e2 as well as the OpenWRT package feeds from GitHUB to the commit fab13041b3a970a302e843fdc11cb6420b6ea9bc. After that, I rebuilt my OpenWRT from scratch (after a make dirclean) and notice any packages written in C++ will give an error message of ambiguous overload for 'operator<<'. For instance, the squid package gives the following error message. I don't know what causes this but it compiled OK before I did the updates. My build is for PLXTECH/Oxford NAS782x/OX82x target system using GCC 4.8.x Linaro enhancement with Preferred standard C++ library (libstdc++). I certainly will appreciate if anyone here will help.

libtool: compile:  arm-openwrt-linux-uclibcgnueabi-g++ -DHAVE_CONFIG_H -I../.. -I../../include -I../../lib -I../../src -I../../include -I/opt/openwrt-git-trunk/staging_dir/target-arm_mpcore_uClibc-1.0.9_eabi/usr/include -I/opt/openwrt-git-trunk/staging_dir/target-arm_mpcore_uClibc-1.0.9_eabi/usr/include -I/opt/openwrt-git-trunk/staging_dir/target-arm_mpcore_uClibc-1.0.9_eabi/include -I/opt/openwrt-git-trunk/staging_dir/toolchain-arm_mpcore_gcc-4.8-linaro_uClibc-1.0.9_eabi/usr/include -I/opt/openwrt-git-trunk/staging_dir/toolchain-arm_mpcore_gcc-4.8-linaro_uClibc-1.0.9_eabi/include -Wall -Wpointer-arith -Wwrite-strings -Wcomments -Wshadow -Werror -pipe -D_REENTRANT -I/opt/openwrt-git-trunk/staging_dir/target-arm_mpcore_uClibc-1.0.9_eabi/usr/include -O2 -pipe -march=armv6k -mtune=mpcore -fno-caller-saves -fhonour-copts -Wno-error=unused-but-set-variable -Wno-error=unused-result -mfloat-abi=soft -Wformat -Werror=format-security -D_FORTIFY_SOURCE=1 -Wl,-z,now -Wl,-z,relro -std=c++11 -MT PortCfg.lo -MD -MP -MF .deps/PortCfg.Tpo -c PortCfg.cc  -fPIC -DPIC -o .libs/PortCfg.o
In file included from ../../src/comm.h:14:0,
                 from PortCfg.cc:11:
../../src/StoreIOBuffer.h: In function 'std::ostream& operator<<(std::ostream&, const StoreIOBuffer&)':
../../src/StoreIOBuffer.h:64:28: error: ambiguous overload for 'operator<<' (operand types are 'std::basic_ostream<char>' and 'const int64_t {aka const long long int}')
     return os << "ioBuf(@" << b.offset << ", len=" << b.length << ", " <<

With risk of stating the obvious...

In plain C, << is a shift operator.  ( 2<<1 = 4 )
In C++, << can be the shift operator. But it is overloaded for IO, making it possible to write

outputstream << "Hello World".

The error appears to be that there are two variables (types: basic_ostream<char> and const int64_t) and for some reason the compiler does not figure out that it should use IO-<< (rather than bit shift, which I doubt is the intention).

It seems far fetched that it should consider the basic_ostream object an interger to shift (although it is a pointer).
It seems more likely that it has some problems with the const long long int.

My spontaneous ideas would be to
a) cast b.offset and b.length to int32 to see if it helps ((int32_t)(b.offset)
b) set all the outputs on separate lines:

  os << "ioBuf(@";
  os << b.offset;
  os << ", len=";
  os << b.length;
  os << ", "

Of course, it could be nicer to isolate the problem in a separate program.

Reading the C++ reference:
http://www.cplusplus.com/reference/ostr … tor%3C%3C/

It seems that this operator does not take "long int" in C++98.
It seems to take more types (at least long long) in C++11.
I dont see any relevant differenc between "long long" and "long long int", but it could confuse the compiler, perhaps.
Perhaps you can try to add a C++11 flag. (-std=c++11 perhaps)

Maybe this code has never been 64-bit before, and breaks now when it is. Maybe something has enabled 64-bit file sizes, replacing 32-bit integer types with 64-bit, which in turn confuses C++ compiler?

Apologizes if I ONLY stated obvious things here!

Ooops ... sorry that I lost track on this post.

I have not tested much, but it looks like yYour suggestion on casting to int32 seems to work. Nevertheless, I sure would like to know why such an upgrade triggered this problem.

The discussion might have continued from here.