Re: compiling libstdc++ with -fhonor-std

[Nathan Myers <ncm at cantrip dot org>]

Matthias Klose (doko@cs.tu-berlin.de) writes:
> On http://www.debian.org/Bugs/db/26/26436.html a request was made to
> compile libstdc++ with -fhonor-std as a default. I simply want to ask, 
> why that's not the default.
> 
> > Would this libstdc++ still be binary compatible with the one compiled
> > without -fhonor-std? Sorry for my ignorance but I'm not a C++
> > developer. Would the compilation with -fhonor-std be conformant with
> > the LCS?
> 
> No, since it changes the mangled names of all symbols in the standard
> C++ library. But the C++ standard dictates all symbols in the library
> must be in the std namespace, so we should use -fhonor-std anyway.
> If we don't switch now we'll have to make the switch later, which might
> be more painful.

We don't compile with -fhonor-std by default yet for several reasons.
The main one is that it would break everything.  In particular, it
would break anything that relies on C headers.

The standard C headers are supposed to put their names in std::, but 
that is not ready yet, partly because implementing it properly requires 
a change in the compiler.

This is discussed more fully (along with a lot of other C++ library
policy issues) in 

  http://sourceware.cygnus.com/libstdc++/design.txt

The compiler change required is a name-mangling hack to allow types
in C headers to be declared in a way that allows third-party 
C headers to "forward-declare" struct tags in the "wrong" namespace
without breaking everything.  One possible implementation would be
a conforming extension

  extern "C-global" { 
    // declare structs here
  }

for use in certain C++-aware C headers, such as the standard C headers.

Examining the headers under the directory shadow/, and the file
http://www.cantrip.org/cheaders.html, might suggest the magnitude
of the issue.

Nathan Myers
ncm@cantrip.org