This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: #include_next and removing of duplicate include dirs
On Sun, Sep 30, 2001 at 11:40:18AM -0400, Phil Edwards wrote:
> > | Wouldn't it be simpler and easier in the long run to cooperate
> > | with the C library?
> >
> > Yes, that was mentionned sometime ago (probably just before we
> > released gcc-3.0) but there is no concretization yet -- at least
> > if memory serves me well.
>
> I think you're correct (again, if my own memory serves me well).
> For glibc, we just need to convince the glibc maintainers to allow
> C++ constructs in their headers, and (again, IIRC) they historically
> have been unwilling to do anything but C. But given that they are
> chock full of GNU extensions, adding "#ifdef __cplusplus" shouldn't
> hurt. I don't the conversation ever went any further.
They do already have extern "C" markers. I have no idea how much more
complex it would be to do what the C++ standard wants, however, it
seems like a lot of it would fall into the category of _not_ doing
things that I personally think glibc shouldn't do in the first place.
Such as the "optimized" string macros.
> For Solaris and similar systems, I don't remember what the most
> recent problem was when their C++-aware headers get activated by our
> compatability attempts. Multiple definitions of size_t and other
> stddef types, I think.
At least in theory, this is just a matter of figuring out how their
headers work and interfacing to them properly, yes? I would volunteer
to help out if I still had a Solaris box to play with, but I don't.
zw