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
