Re: Problem with `string', threading and shared libraries.

[Loren James Rittle <rittle at latour dot rsch dot comm dot mot dot com>]

In article <Pine.SOL.3.91.1010928144847.1366B-100000@taarna.cygnus.com>:

>> Well, using different compilers can always result in different
>> mangling for std::string.  In this case, it's the same version of GCC
>> built with different configure arguments, but the configure arguments
>> still make them different compilers.

> We're talking about the same compiler here, same library version numbers.

> I believe it's possible to use a gcc-pthreads compiler to link 
> gcc-non-pthreads "C" libraries, for instance. I see no reason why C++ 
> should be any different.

> Please correct me if I'm wrong.

Just so we all know the current state (I was directly asked to provide
input in another part of this thread), here is my summary of what I
believe to be true.  I think this is basically documented in the
various documentation and FAQs as shipped with the library.

As of gcc 3.0, the C++ library built with --enable-threads is *NOT* an
ABI change from one built with --disable-threads in terms of
user-level symbol names changing their mangling, etc.  However, due to
implementation changes in light of those flags (i.e. whether a mutex
is actually locked or not for a code path), it is possible that things
will not work as well as possible if you link some code compiled with
one configuration verses another.  The basic rule is that if threading
is to work, all code must have been compiled and linked with a
compiler built with the same --enable-threads configure-time option.
Part of the problem is that this ABI is not contained to linked-in
items but rather sometimes inlined into user code.  I do believe this
to be true: if you build the C++ library code with --enable-threads
then you should be able to link against user-code that was compiled
with a compiler configured with --disable-threads.

This was the situation after my threading patches which made
libstdc++-v3 use the gthr abstraction layer for gcc 3.0 instead of the
ad hoc pthread support.  The situation was worse before that.  People
that use the _NOTHREADS macro are basically getting the V2 situation.

My best advice to Carlo is to not define _NOTHREADS.  People that do
that get a documented ABI change...

There are patches to allow the selection of the gthr abstraction layer
to be made dynamically.  However, they were never applied due to
remaining issues.  Patches from Carlo to fix a problem because he
insists upon being able to define a macro in implementor space when he
compiles user code should never be accepted.

Regards,
Loren
-- 
Loren J. Rittle
Senior Staff Software Engineer, Distributed Object Technology Lab
Networks and Infrastructure Research Lab (IL02/2240), Motorola Labs
rittle@rsch.comm.mot.com, KeyID: 2048/ADCE34A5, FDC0292446937F2A240BC07D42763672