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.
