Re: More fallout from global.cc namespace changes

[Benjamin Kosnik <bkoz at redhat dot com>]

> Correct me, if I'm wrong but transfering this patch breaks all
> static linking of 3.2 objects against 3.2.1 objects assuming
> a namespace moved name is referenced.  I guess I really have
> no objection as long as we understand and document the situation.

I don't anticipate any static linkage issues. 

All "namespace moved names," as far as I understand it, have been
explicitly renamed to be compatible, as in the following
foolish-yet-legal example:

#include <locale>

// From 3.2.0
namespace std
{
  extern locale 		c_locale;
}

// From 3.2.1
namespace __gnu_cxx
{
  extern std::locale 		c_locale;
}

int main()
{
  // Sadly, this should work, by mistake this was exported.
  void* p = &std::c_locale;

  // Shouldn't work, because we will never be so stupid again.
  void* p2 = &__gnu_cxx::c_locale;
}

You'll get (with both 3.2.0 and patched 3_2-branch)

%g++ three2compat.cc 
/tmp/ccOqlDGi.o(.text+0x1a): In function `main':
: undefined reference to `__gnu_cxx::c_locale'
collect2: ld returned 1 exit status

The only (arguable) things referenced of the bits in src/globals.cc were
the cout/cin/cerr bits which are in namespace std and were not touched,
and your argument for the thread bits.

I'm not certain about your argument, but it seems reasonable and in any
case is easy to accomodate.

> It does seem that more than mere bug fixes are being moved to the
> branch at the last hour (Joe has already written and posted the
> 3rd draft of release notes for 3.2.1!)

I think this patch is necessary to keep the 3_2-branch maintainable. It
can be done, so I think it should be.

-benjamin