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

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

In article <20010929055414.A10587@alinoe.com> you write:
>On Fri, Sep 28, 2001 at 06:40:28PM -0300, Alexandre Oliva wrote:
>> > If they are really considered to be two different classes, then
>> > "std::string" is a truly bad choice.  
>> 
>> 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.
>
> Actually, this was all on my own machine - using one and the same
> compiler.   I compiled my library with a #define _NOTHREADS
> (because it is not supporting threads), and then got 'undefined
> symbols' in test applications that did not define _NOTHREADS
> (although they were also not threaded).

Where in the libstdc++ documentation does it say that *you* as a user
of the library should be defining a macro which is in the implementor
namespace (_NOTHREADS)?

This is a situation where you shot yourself in the foot by presuming
too much implementation knowledge of the library.

I am willing to be blamed for not having done enough to improve
libstdc++-v3 before the gcc 3.0 release, but IMHO the situation at gcc
3.0 release related to threading was better and better documented than
any past gcc release of a C++ library.

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