C++ has a fundamental design problem which neither C nor scripting languages share.
C is more or less a portable assembly language, with minimal abstraction between the programmer and what the machine is doing. If you want to know how something is implemented you can dig in and get all the details, even write your own replacement version (uClibc, musl, dietlibc, klibc, newlib...).
Scripting languages like python, ruby, lua, and so on abstract away memory management and type conversions, providing opaque abstractions that you can use without caring how they're implemented. Is a dictionary a hash table or a tree? Is the garbage collector mark and sweep or reference counting? It doesn't matter, it just works. Scripting languages even do away with the source/binary distinction, running the source code directly with no need for makefiles.
C++ provides thick layers of abstraction built on top of manual resource management and static typing, but most of all on top of pointers (instead of references). C++'s abstractions leak implementation details, and C++ advocates blame programmers for "not using the language right". As for the complexity of the build process, templates are literally turing complete at compile time (there's no guarantee a C++ program compilation will ever terminate) and teaching a debugger to name demangle a function pointer to an overloaded member function in a virtual base class is hard enough without bringing cross compiling into it.
This is a fundamental problem: C is a simple language because it has no abstraction, scripting languages are simple by having opaque abstractions that truly hide complexity. C++ provides leaky abstractions that embody enormous complexity but require knowledge of their implementation details down to the hardware to use correctly. Most of the complexity of C programs comes from the program. A significant part of the complexity of C++ programs comes from the language.