https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100057
--- Comment #41 from cqwrteur <unlvsur at live dot com> --- (In reply to Jonathan Wakely from comment #38) > (In reply to Nicolas Noble from comment #33) > > At the moment, I don't understand if it's possible to spawn a cross compiler > > with a freestanding libc and libstdc++. > > A GCC bootstrap needs a hosted libstdc++, because it's built with C++. If > you want to disable hosted libstdc++ you need to also build with > --disable-bootstrap. > > > (In reply to Nicolas Noble from comment #34) > > After some digging, I found out this in the acinclude.m4 file of the > > libstdc++-v3 folder: > > > > AC_DEFUN([GLIBCXX_ENABLE_HOSTED], [ > > AC_ARG_ENABLE([hosted-libstdcxx], > > AC_HELP_STRING([--disable-hosted-libstdcxx], > > [only build freestanding C++ runtime support]),, > > [case "$host" in > > arm*-*-symbianelf*) > > enable_hosted_libstdcxx=no > > ;; > > *) > > enable_hosted_libstdcxx=yes > > ;; > > esac]) > > > > > > Basically, it looks like the "disable hosted libstdc++" flag is only honored > > when building on a host triple that's arm + symbian. > > No, that code snippet is the action-if-not-given clause, which means it runs > if you do not use --disable-hosted-libstdcxx or --enable-hosted-libstdcxx, > i.e. the default for symbian is freestanding, the default for other systems > is hosted. But you can override the default. > > > The documentation + > > reporting for this is extremely misguiding. The documentation should at > > least specify this only works in a very narrow context, and the configure > > script should probably error out if the user asks for a feature it can't > > actually provide. > > No, the docs don't say that because it's not true, you've just completely > misunderstood the configure script. > > > I'm closing this bug, because "cqwrteur" is a moron who can't report useful > bugs. > > If you need help building freestanding please use the gcc-help mailing list, > or the libstdc++ list, or open a new bug. Stay away from everything cqwrteur > reports, because it's toxic garbage and I'm not interested in dealing with > his nonsense. lol. who is the true moron? std::addressof, std::array and std::move etc are not freestanding but bitching C programmers use C for writing kernel and embedded. When will be herbceptions? C++ EH is a total historical mistake. C++ is an absolute joke for embedded and kernel developments. From: Linus Torvalds Subject: Re: Compiling C++ kernel module + Makefile Date: Mon, 19 Jan 2004 22:46:23 -0800 (PST) On Tue, 20 Jan 2004, Robin Rosenberg wrote: > > This is the "We've always used COBOL^H^H^H^H" argument. In fact, in Linux we did try C++ once already, back in 1992. It sucks. Trust me - writing kernel code in C++ is a BLOODY STUPID IDEA. The fact is, C++ compilers are not trustworthy. They were even worse in 1992, but some fundamental facts haven't changed: - the whole C++ exception handling thing is fundamentally broken. It's _especially_ broken for kernels. - any compiler or language that likes to hide things like memory allocations behind your back just isn't a good choice for a kernel. - you can write object-oriented code (useful for filesystems etc) in C, _without_ the crap that is C++. In general, I'd say that anybody who designs his kernel modules for C++ is either (a) looking for problems (b) a C++ bigot that can't see what he is writing is really just C anyway (c) was given an assignment in CS class to do so. Feel free to make up (d). Linus Linus is totally correct.