On Fri, Jul 4, 2008 at 4:07 PM, Richard Guenther
<richard.guenther@gmail.com> wrote:
On Fri, Jul 4, 2008 at 11:02 PM, Gabriel Dos Reis
<gdr@integrable-solutions.net> wrote:
On Fri, Jul 4, 2008 at 3:57 PM, Richard Guenther
<richard.guenther@gmail.com> wrote:
On Fri, Jul 4, 2008 at 10:43 PM, Gabriel Dos Reis
<gdr@integrable-solutions.net> wrote:
Also we don't want any runtime initialization to be snick in.
This is the
reason why I don't it be compiled with a c++ compiler.
If you don't have runtime initialization when compiling with C,
you won't
have one when compiling with a C++ compiler.
You won't notice if they snick in though.
How does that happen for a library that is compilable with both a C
and C++ compiler?
At the point we only compile it with a C++ compiler.
I understand mainline being in form that is compiled with *both*
a C compiler and a C++ compiler, so this scenario never
happens.
I understand gcc-in-cxx as the branch we do everything with a C++
compiler. There, there needs to be conscious decisions made
and I hope those decisions will keeping in mind that systems
are built with C++ compiler without dragging in the runtime system.
So, to my mind, mainline is very different from gcc-in-cxx.
Also I'd be more nervous with
silently changing the ABI of said library if we compile with a C+
+ compiler.
That is valid worry point. And it needs to be addressed.
Concretely in this case, where
(1) all declarations should be wrapped in an extern "C" declaration
-- see discussion
with Ian on gcc@
(2) all datatypes are PODs -- therefore follow C ABI,
(3) the code is a the intersection of GNU C and GNU C++,
where do you see potential for ABI change? This isn't a rhetorical
question since
we do want to make sure that we don't run into a silent ABI change.
Why take the risk? Why not build libgcc with a C compiler?
I was hoping an informative answer. Naturally, the question can
also be
`why not a C++ compiler' like the rest of the compiler.
The question `Why take the risk' suggests unknowns -- which I was
trying
to get at by listing the conditions around libgcc. Maybe I've
forgot some, but
I'm genuinely trying to get us spell out the conditions around libgcc.
I hope we don't build libgcc with a C compiler just because `we
don't know'.
I really don't understand why we are now trying to build _everything_
with a C++ compiler. I thought this was about the compiler only.
I thought libgcc was part of the compiler.