Re: Included Interfaces without documentation update
Dan Kegel <dank@kegel.com> writes:
> Dan Kegel wrote:
> > > > 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.
> > > ...
> > > 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?
>
> Getting back to the original topic, it looks like the documentation
> for the symbols
> _IO_2_1_stderr_
> _IO_2_1_stdin_
> _IO_2_1_stdout_
> _IO_feof
> _IO_getc
> _IO_putc
> _IO_puts
>
> could be something like this:
>
> These are internal aliases used in the interface between glibc and
> gnu stdlibc++ for the symbols stderr, stdin, stdout, feof, getc,
> putc, and puts. Use programs should not directly reference these.
> These are only used by programs that link statically to gnu libstdc++.
> These may be deprecated in a future version of this standard, once
> the final C++ ABI is deployed.
>
> Andreas, is that accurate?
According to my understanding (I'm not a libstdc++ developer): Yes,
that's fine.
> Are there other symbols that fall in this category?
I don't have access at the moment to the current LSB and therefore
can't check this. But if there're other symbols starting with _IO_,
they fail into the same category.
Andreas
--
Andreas Jaeger
SuSE Labs aj@suse.de
private aj@arthur.inka.de
http://www.suse.de/~aj
Reply to: