libio fails on glibc2 linux [was: Latest snapshot 971225]

[Andrey Slepuhin <pooh at msu dot ru>]

Andrey Slepuhin wrote:
>> I just found why there is a regression with egcs-971215 on
>> i*86-pc-linux-gnu configurations (somebody reported this but
>> I don't remember any fixes) during compilation of tstring.cc
>> in libstdc++ tests. Errors were because first parameter
>> of __default_alloc_template<bool threads,int inst> depends
>> whether defined _PTHREADS symbol. For an unknown matter
>> libstdc++ modules in i*86-pc-linux-gnu configuration always
>> compiled with -D_PTHREADS, so default allocator "alloc"
>> in libstdc++ is treated as __default_alloc_template<true,0>,
>> while during compilation of tstring.cc it is treated as
>> __default_alloc_template<false,0>. This cause undefined
>> symbols during link stage.
Orn E. Hansen wrote:
> 
>   A few days ago, there was a posting here, explaining the reason why strings
> have failed in the last two snapshots.  The reason being tstring.cc, that was
> compiled with alloc_template<false,0>, while other instances of c++ were
> compiled with alloc_template<true,0>.  Looking at the snapshot, I couldn't see
> any changes in this, and wanted to inquire if anyone had found a way to have
> strings work with?

Unfortunately, I cannot make appropriate fix due to the following
reasons:
_PTHREADS symbol was added in September by Ulrich Drepper, but
regressions became visible after Jody Goldberg's rewrite of
basic_string.
I don't know how stable is current basic_string implementation and what
are the relations between _PTHREADS symbol in libstdc++ and
the same one in Teemu's mt-eh changes (unfortunately, current egcs tree
only includes mt-eh config for sparc solaris:().
If libstdc++ on i*86-pc-linux-gnu  always needs _PTHREADS symbol (even
if
we don't need multithreaded environment), then the problem should be
fixed
by instantiating both __default_alloc_template<true,0> and
__default_alloc_template<false,0> in libstdc++. Otherwise, we should
change configuration files.

Andrey.