This is the mail archive of the
mailing list for the libstdc++ project.
Re: Problem with `string', threading and shared libraries.
- To: libstdc++ at gcc dot gnu dot org
- Subject: Re: Problem with `string', threading and shared libraries.
- From: Loren James Rittle <rittle at latour dot rsch dot comm dot mot dot com>
- Date: Mon, 1 Oct 2001 20:38:12 -0500 (CDT)
- Cc: rittle at latour dot rsch dot comm dot mot dot com
- Organization: Networks and Infrastructure Lab (IL02/2240), Motorola Labs
- References: <20010928164914.A32098@alinoe.com>
In article <email@example.com> you write:
>Carlo Wood <firstname.lastname@example.org> writes:
>| I really think that it was a wrong decision to include
>| thread-safeness in the mangling of std::string.
> So we're at least two then.
When you agree with Carlo on this matter, be sure you fully understand
what you are agreeing to.
He had compiled libstdc++ with a macro, reserved to the
implementation, defined and then he compiled his user code without
that macro defined. Nowhere do we document that macro being used by
normal users of the library.
Here is what we say in internal configuration documentation of the
library, libstdc++-v3/include/bits/c++config :
// [...] Note:
// that gthr.h may well map to gthr-single.h which is a correct way to
// express no threads support in gcc. As a user, do not define
// _NOTHREADS without consideration of the consequences (e.g. it is an
// internal ABI change).
Note that it is explicitly marked as something that will change the
ABI (i.e., you can't link code compiled with and without that macro
defined). I honestly don't know how much more of a warning is merited
for a symbol outside the normal user-space.
The main reason I did not entirely remove support for that macro was
that it was used in the SGI STL code.
Loren J. Rittle
Senior Staff Software Engineer, Distributed Object Technology Lab
Networks and Infrastructure Research Lab (IL02/2240), Motorola Labs
email@example.com, KeyID: 2048/ADCE34A5, FDC0292446937F2A240BC07D42763672