Re: More fallout from global.cc namespace changes

[Loren James Rittle <rittle at latour dot rsch dot comm dot mot 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.

> ?

I am beginning to see that you and I are greatly concerned about
somewhat different things (and I am only concerned because you asked
me to consider this).  I am concerned about the names of symbols
exposed by the installed headers.  You are concerned about the names
of things exported from the shared library.

GCC 3.2.X as built on freebsd4:

; nm /usr/local/lib/libstdc++.so.5|grep _S_swap_lock
000541c8 d _ZNSt17_Swap_lock_structILi0EE12_S_swap_lockE

I agree that symbol is "local".  I.e. not exported from the shared
library.  That may or may not be OK based on usage of that particular
lock...

Looking at linker-map.gnu, I agree the symbols of the other path are
not exported either...  That is NOT right.  There shall be only one
_GLIBCPP_mutex in the entire running system (or at most one per set of
code that shares particular template instantiations).  If that
assumption is not held, I'm fairly sure races exist...  Whether these
races actual affect anything in practice is unknown to me.

Now on to my concern (at least the issue I think I have been raising,
it doesn't affect me so I guess I don't care too much):

Huh, the definition (including name space) of those quoted lines of
code haven't changed since GCC 3.0 was released!  Where did we say
that we would be allowed to break the ABI on a release branch for
ports and/or situations (include static links?) that fail to use
linker-map.gnu?

To state my objection to the patch another way: Just beacuse it is not
exported from the shared library doesn't mean that when we link object
1 created with gcc 3.2 against object 2 created with gcc 3.2.1 we may
fail with ABI-related issues.

In object 1, I will have a reference to std::_GLIBCPP_mutex and in
object 2, I will have a reference to __gnu_cxx::_GLIBCPP_mutex.
How does that program properly link against the static library?
How does that program properly link against the shared library
that was built without symvers support?

The whole point of not breaking the ABI on the release branch dictates
that certain name changes in exposed headers are not allowed...

Does my position make sense?

Regards,
Loren