Re: More fallout from global.cc namespace changes

[Benjamin Kosnik <bkoz at redhat dot com>]

> I am unsure that I'm happy with Danny's patch as committed (sorry, I
> *never* read list traffic on weekends ;-).  I am happy with it, if the
> related patch set will never move to the 3.2 branch and/or we
> explicitly document an issue for any port supporting threads without
> support for a static init mutex.  I am somewhat concerned at any name
> change related to this mutex since code compiled before the name
> change will silently not share the same mutex with code compiled after
> it.  I.e.  effectively different locking protocols will be in affect
> thus allowing for memory corruption if there is any contention on the
> locked item.

Hmm. Not quite sure I follow you.

#ifdef __GTHREAD_MUTEX_INIT
  // Need to provide explicit instantiations of static data for
  // systems with broken weak linkage support.
  template __gthread_mutex_t _Swap_lock_struct<0>::_S_swap_lock;
#elif defined(__GTHREAD_MUTEX_INIT_FUNCTION)
  __gthread_once_t _GLIBCPP_once = __GTHREAD_ONCE_INIT;
  __gthread_mutex_t _GLIBCPP_mutex;
  __gthread_mutex_t *_GLIBCPP_mutex_address;
  
  // Once-only initializer function for _GLIBCPP_mutex.  
  void
  _GLIBCPP_mutex_init ()
  { __GTHREAD_MUTEX_INIT_FUNCTION (&_GLIBCPP_mutex); }

  // Once-only initializer function for _GLIBCPP_mutex_address.  
  void
  _GLIBCPP_mutex_address_init ()
  { __GTHREAD_MUTEX_INIT_FUNCTION (_GLIBCPP_mutex_address); }
#endif

None of these were exported in 3.2.0.

? 

benjamin