libc++ - stop std renaming to std::__1?

After substantial effort getting clang and libc++ to compile, run, integrate with NetBeans, and even cross-compile to a 32-bit machine, I thought I had it all figured out! So I go to use some features that libstdc++ didn't have (the entire reason for turning my dev environment upside down), and discover... I can't actually do that.

libc++ is installed, it works, and the compiled program (when it works) does require it. However, the compiler still tries to use libstdc++ versions at every opportunity, by messing with the namespace; std::__1::map, std::__1::basic_string, and so on. Now, I know from this question why that happens, and why libc++ does it. I just need to know how to obliterate it, because it's completely inapplicable - I really, truly do want to use the libc++ versions, and there is nothing in my code that would require the two types to coexist.

I've tried taking the libstdc++ folders out of the include path, and, failing, that, made them completely inaccessible. No luck. I'm not using any add-on libraries, only built-in Linux/POSIX headers (errno, socket, syslog, fcntl).

EDIT: Error message:

CoreCache.cpp:61:12: error: no member named 'emplace' in 'std::__1::map<std::__1::basic_string<char>, CacheEntry, std::__1::less<std::__1::basic_string<char> >, std::__1::allocator<std::__1::pair<const std::__1::basic_string<char>, CacheEntry> > >'

The libstdc++ map does not have emplace(). The libc++ version does.

The following invocation, from the command line, seems to work:

clang++ -o stachecache -I /usr/local/lib/clang/3.1/include/ -I /usr/include/c++/v1/ -std=c++0x -stdlib=libc++ ./*.cpp

The invocation from within NetBeans does not:

clang++ -stdlib=libc++ -O3   -c -O3 -Werror -MMD -MP -MF build/Release/clang-Linux-x86/CoreCache.o.d -o build/Release/clang-Linux-x86/CoreCache.o CoreCache.cpp

From the comments:

araqnid: Your NetBeans invocation doesn't have -std=c++0x, is it not needed? std::map::emplace is a C++11 method.

DigitalMan (OP): @araqnid That actually did it! Clang complained about that argument being unused - and still does, in fact, even when it's used and required - so I had taken it out of the NetBeans configuration. A faulty warning is better than a complete error, certainly.