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? Are there other symbols that fall in this category? - Dan
