Re: Development status

[Nathan Myers <ncm at cantrip dot org>]

On Tue, Apr 11, 2000 at 12:02:52AM +0200, Martin v. Loewis wrote:
> Nathan wrote:
> > Indeed, most of this work has already been done, in the shadow/
> > directory. (See also http://www.cantrip.org/cheaders.html .)
> 
> I don't mean to belittle your work, but I think that this approach is
> essentially a work around "broken" C libraries. This work-around has
> to be used on systems where we don't supply the C library.

Correct.  We have to have such support anyway, and it had better
work well enough.  Getting glibc support directly has to be lower
priority for the project -- although of course people will work 
on what they like, regardless, and a fully-integrated glibc and
libstdc++ would be cool and useful.
 
> On a GNU system, we have full control over every single source line in
> the system. So we can make it work how we would like it to work,
> without having to put one kludge on top of another.

We still have version problems -- glibc and gcc do not synchronize
releases, and glibc is not ported nearly so widely as gcc.

I agree it would be nice to make shadow/ superfluous for GNU systems.
Extracting code from it into glibc-2.2 would make that job easier,
because it has already identified all the cases where the C++ version
differs from the C library.  We should be careful, though, not to 
interfere, in glibc, with the shadow/ implementation, because (1) that 
would make it hard to test shadow/, and (2) it would make workarounds 
for glibc bugs, misfeatures, and version mismatches hard.
 
> > We just need to set it up as the default installation, and finish up 
> > any loose ends.  It had appeared to me that some minor compiler changes,
> > such as were implemented by Sun, SGI, and DEC, would improve matters, 
> > but Martin has disagreed with that, so probably we should proceed 
> > without, and see.  
> 
> Well, I may disagree, but I still provided a patch to implement the
> feature that you requested. I'm not that much pushing for inclusion of
> that patch, that is true.

I didn't know there was such a patch.  Where can I find out more 
about it?
 
> > That is one possible implementation.  What the standard requires
> > is (1) the types be actually defined in std::, and (2) the function
> > names be declared in std::, although they may also be visible
> > globally.
> 
> Where exactly does the standard allow the names to be visible
> globally? 17.4.1.1/2
> 
> # All library entities except macros, operator new and operator delete
> # are defined within the namespace std or namespaces nested within
> # namespace std.
> 
> Seems pretty clear to me.

Me too, but the committee chose to muddy the water: 

17.4.2.2 - Linkage [lib.using.linkage]
  -2- It is unspecified whether a name from the Standard C library 
  declared with external linkage has either extern "C" or extern 
  "C++" linkage.

17.4.3.1.3 - External linkage [lib.extern.names]
  -4- Each name from the Standard C library declared with external
  linkage is reserved to the implementation for use as a name with
  extern "C" linkage, both in namespace std and in the global 
  namespace.

Sun and DEC demanded latitude to spew all over the global namespace.
 
> > We should design for the desired end result, in this case full standard
> > compliance and future compiler versions.  In particular, we should
> > work on the assumption that programs linked with libstdc++-v3 will be 
> > built with -fhonor-std and -fnew-abi if on gcc-2.95.2.  The build 
> > instructions should reflect that.
> 
> Use of -fnew-abi is strongly discouraged, it is an experimental
> feature and subject to change without notice. I don't see why that is
> required for gcc 2.95.2; if -fsquangling is what you really want, then
> use that.

Hey, libstdc++-v3 is an experimental library.  We have to get the
new ABI nailed down, and gcc-3 will probably be our last chance to
do it.  We had better work out any problems now, and freeze the ABI 
as soon as possible.  The only way that can happen is if people 
using snapshots of libstdc++-v3 routinely use -fnew-abi.  That's OK, 
because they don't expect binary compatibility between versions
anyway.

Nathan Myers
ncm@cantrip.org