clang libc++ error: overload resolution selected implicitly-deleted copy assignment operator

Question

I can't get a C++11 project using clang 3.1 to compile. The command to the compiler is this:

clang++-mp-3.1 -c -std=c++11 -stdlib=libc++ -Wall -g -Iinclude -I/usr/local/include -I/opt/local/include -I/usr/local/include/mongo -o world.o world.cpp

And the error I get, since I included the "-stdlib=libc++" directive, is this:

In file included from world.cpp:1:
/usr/include/c++/v1/string:1952:10: error: overload resolution selected implicitly-deleted copy assignment operator
    __r_ = _STD::move(__str.__r_);
         ^
/usr/include/c++/v1/string:1942:9: note: in instantiation of member function 'std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> >::__move_assign' requested here
        __move_assign(__str, true_type());
        ^
/usr/include/c++/v1/string:1961:5: note: in instantiation of member function 'std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> >::__move_assign' requested here
    __move_assign(__str, integral_constant<bool,
    ^
/usr/include/c++/v1/utility:200:24: note: in instantiation of member function 'std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> >::operator=' requested here
struct _LIBCPP_VISIBLE pair
                       ^
/usr/include/c++/v1/memory:1941:5: note: copy assignment operator is implicitly deleted because '__compressed_pair<std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char>
      >::__rep, std::__1::allocator<char> >' has a user-declared move constructor
    __compressed_pair(__compressed_pair&& __p)
    ^
1 error generated.

Can anyone advise me on how I can get this to work?

The file I'm trying to compile doesn't even have to include any C++11 code for this error to occur, the "-stdlib=libc++" directive alone is enough to make it break.

Thanks for any & all assistance, Doug.

UPDATE: Hi -- the code is pretty basic, but in making it as basic as possible, I came across this error:

Undefined symbols for architecture x86_64:
  "std::__1::cout", referenced from:
      _main in world.o
  "std::__1::basic_ostream<char, std::__1::char_traits<char> >::sentry::sentry(std::__1::basic_ostream<char, std::__1::char_traits<char> >&)", referenced from:
      std::__1::basic_ostream<char, std::__1::char_traits<char> >& std::__1::operator<< <std::__1::char_traits<char> >(std::__1::basic_ostream<char, std::__1::char_traits<char> >&, char const*) in world.o
  "std::__1::ios_base::clear(unsigned int)", referenced from:
      std::__1::basic_ostream<char, std::__1::char_traits<char> >& std::__1::operator<< <std::__1::char_traits<char> >(std::__1::basic_ostream<char, std::__1::char_traits<char> >&, char const*) in world.o
  "std::__1::basic_ostream<char, std::__1::char_traits<char> >::sentry::~sentry()", referenced from:
      std::__1::basic_ostream<char, std::__1::char_traits<char> >& std::__1::operator<< <std::__1::char_traits<char> >(std::__1::basic_ostream<char, std::__1::char_traits<char> >&, char const*) in world.o
  "std::__1::ios_base::__set_badbit_and_consider_rethrow()", referenced from:
      std::__1::basic_ostream<char, std::__1::char_traits<char> >& std::__1::operator<< <std::__1::char_traits<char> >(std::__1::basic_ostream<char, std::__1::char_traits<char> >&, char const*) in world.o
ld: symbol(s) not found for architecture x86_64
clang: error: linker command failed with exit code 1 (use -v to see invocation)

To get this error, I stripped my code back to this:

#include <iostream>
int main( int argc, char *argv[] )
{
  std::cout << "Hi.\n";
}

Which makes this look like something pretty fundamentally wrong.

I don't get this error when I take out the "-stdlib=libc++" directive to the compiler.

Answer 1

Perhaps you should consider installing clang from llvm itself. This can be found here . I am not 100% sure but perhaps macports or similar has compiled your version against a different gcc than you have installed. The llvm downloads are compiled against the gcc that in installed and should prove ABI compatible.

You can also upgrade the libc++.dynlib if you follow the instructions in llvm, but be aware a great many progs in MAC depend on this so you must make a copy of the existing lib (just in case). If you want bleeding edge you may need to dive into these changes. I have done this on a mac and it was perfectly fine and can compile c++11 code just fine.

To build libc++ see here

Answer 2

There's a similar question here .

In short, when this happens it is because one of the possible overloads was declared as forbidden, hence the overload resolution fails. To get around it you should explicitly cast to make that forbidden overload not be one of the resolutions for the call.

See the accepted answer to the linked question for a very detailed and well written explanation.