Re: Linux vs. libio

[Joe Buck <jbuck at synopsys dot COM>]

Mark Mitchell writes:

> >   o I'm not proposing changing *anything* about libio when compiled
> >     with the existing C++ ABI, which will continue to be supported
> >     indefinitely.
> > 
> >   o I'm proposing chaning libio, conditionally, when compiled with the
> >     new C++ ABI.  (This is analagous to multilibbing.)  Without doing
> >     so, it will not work.

Geoff Keating writes:
> This is what I'm objecting to.  Perhaps I should draw a diagram.  I
> expect that with -fnew-abi, the version number of libstdc++ will
> change, perhaps to libstdc++.so.3.  Now, suppose I use my brand new
> GCC 3.0.0, with -fnew-abi on by default, under my linux system,
> to compile an executable 'test', and 'netscape' is an old binary-only
> application compiled under the old GCC.
> 
> So we have a shared library use graph that looks like this:
> 
> netscape --> libstdc++.so.2.8 --> libc.so.6
> test	 --> libstdc++.so.3   ----^
> 
> But this won't work with your proposal. 

Are you sure that you understand Mark's proposal?  I ask this because
your assertion is incorrect -- there would be two separate libio's
involved.  (This is not a new thing: we used tricks like these back
in the libc5 days sometimes).

His conditionally changed libio would live inside libstdc++.so.3, and the
C bindings for it would not be exported (exactly as it does on, say,
Solaris platforms).  Suppose test does some C stdio stuff in addition to
the C++ iostreams stuff.  In that case, it would get the iostreams stuff
from libstdc++.so.3, and would get the stdio stuff from libc.so.6.  There
would be two copies of libio in the same address space, one exporting the
C++ bindings and one exporting the C bindings.  The main user-visible
symptom would be that programs like this:

#include <stdio.h>
#include <iostream.h>

main ()
{
	printf ("This should be line 1.\n");
	cout << "This should be line 2.\n";
}

might not work as expected, because stdout and cout will not be
synchronized.  But most things will work just fine.  It would be much
the same as the situation on an OS with a proprietary libc: the
C++ and C i/o code would be separate.

Now, we don't want this as a long-term solution.  But it doesn't have
severe consequences as a temporary solution to be used by developers
and testers.