Re: Included Interfaces without documentation update
Dan Kegel <dank@kegel.com> writes:
> Andreas Jaeger wrote:
> >
> > Dan Kegel <dank@kegel.com> writes:
> >
> > > Andreas Jaeger wrote:
> > > > > > > > > Andreas Jaeger wrote:
> > > > > > > > > > > _IO_putc
> > > > > > > > > > Mangle for putc
> > > > > > > > > > > _IO_puts
> > > > > > > > > > Mangle for puts
> > > > > > > > >
> > > > > > > > > That's interesting. I had no idea there were versions of feof etc.
> > > > > > > > > with C++ linkage in the standard libraries. What standard specifies that?
> > > > > > > >
> > > > > > > > No standard - that's the way glibc implements them. Since LSB is not
> > > > > > > > going to change glibc, we have to document these.
> > > > > > >
> > > > > > > Does it also export them with C linkage, then?
> > > > > >
> > > > > > Definitly - we describe a C ABI here.
> > > > >
> > > > > That's what I thought. Then why are we also describing the mangled
> > > > > names? Seems like a bug to specify C++ mangled names for C library
> > > > > functions.
> > > >
> > > > Stuart has run with appcheck some tests and noticed that some
> > > > programs, most probably C++ applications or libs, needed these, for
> > > > example:
> > > >
> > > > $ nm /usr/lib/libstdc++-3-libc6.2-2-2.10.0.so |grep putc
> > > > U _IO_putc@@GLIBC_2.0
> > > >
> > > > Since LSB supports C++, we have to add those symbols,
> > >
> > > There's nothing technically saying you can't use C linkage in a C++
> > > program; in fact, stdio.h is surrounded by extern "C" { ... }
> > > to force this.
> >
> > We seem to have a communication problem. Those mangles are needed by
> > C++ but have C linkage, they don't have C++ linkage.
>
> 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.
> (I feel strange debating this point with Andreas, who should know better than me!
> What am I missing?)
>
> 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.
>
> 'nm /usr/lib/libc.a | grep puts' shows, among other things,
> ioputs.o:
> 00000000 T _IO_puts
> 00000000 W puts
> 'nm /lib/libc.so.6 | grep puts' shows the same stuff, minus filenames.
>
> As far as I can tell, the prefixed names are internal to glibc.
> User programs don't import them.
C++ programs import them.
> Here's a test case. I compiled the following code with gcc 2.96 (the
> "Red Hat 7 suprise" release):
> #include <stdio.h>
> main() { fputs("howdy", stdout); }
> Running 'nm a.out | grep puts' shows
> U fputs@@GLIBC_2.0
> so indeed, user programs don't see to reference the internal symbols.
>
> 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 )
C++ will break, make an nm on libstdc++ and search for _IO.
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.
Andreas
--
Andreas Jaeger
SuSE Labs aj@suse.de
private aj@arthur.inka.de
http://www.suse.de/~aj
Reply to: