Re: Included Interfaces without documentation update

[Dan Kegel <dank@kegel.com>]

Andreas Jaeger wrote:
> > > > > > > > > > Andreas Jaeger wrote:
> > > > > > > > > > > > _IO_putc
> > > > > > > > > > > Mangle for putc
> > No, mangles *define* C++ linkage.  If it's mangled, it's using C++ linkage.
> 
> I see - we have a linguistic problem.  I'm not a native speaker and
> therefore my wording was not precise.  Let's state it this
> way:_IO_putc is an alias for putc and used by the C++ library.
> >
> > Anyway, it looks like it's *not* a C++ mangle.  Look at this:
> > http://cvsweb.netbsd.org/bsdweb.cgi/gnusrc/gnu/dist/libio/ioputc.c?rev=1.1.1.2
> > The _IO_ prefix is glibc's private little namespace convention
> > for C library calls; they define a weak alias to map the conventional
> > name into their private namespace convention.
> > ...
> > I'm a newbie when it comes to glibc, so perhaps Andreas can
> > explain what the consequences of not exporting the internal prefix
> > versions of C library functions (like _IO_puts)
> > would be.  Since user programs don't reference them, it must
> > be something subtle, like 'virtualfs won't work'
> > (see http://www.solucorp.qc.ca/virtualfs/virtualfs-6.html )
>...
> I don't see directly how it can end in a user program that's linked
> shared against libstdc++ but it will end in a user program that's
> linked static against libstdc++ - and that's the way we advise in the
> LSB to work around the different GCC releases until 3.0 comes out.

Thanks for the explanation.  It worries me that we're mandating
a whole bunch of interfaces which are strictly internal to the
c/c++ standard libraries.  Can these be put into a separate section
of the ABI definition, that can be deprecated later when 3.0 is
out, and we can all happily use dynamic linking?

- Dan