Threads, glibc, and all that

[Mark Mitchell]

>>>>> "H" == H J Lu <hjl@lucon.org> writes:

    >>  hjl@lucon.org (H.J. Lu) writes:
    >> 
    >> > Ulrich, how about putting this in ...../include/g++? We can
    >> check > to see if it is necessary before we install it. I don't
    >> think it > will hurt anything. We can remove it during next
    >> installation when > we determine it is no longer needed. A
    >> patch to libstdc++ shoudn't > be hard.
    >> 
    >> Well, the patch is ok.  But the hack shouldn't be installed
    >> unconditionally (only if the problem is real) and how to remove
    >> it the next time?  We certainly don't want to carry around
    >> baggage from the

    H> If it is ok with everyone, I will provide a patch for libstdc++
    H> by this weekend. It will test before using/installing it and
    H> remove the installed file during "make install" if necessary.

Seems to me that we are spending a lot of time hanging up 1.0.2, which
Jeff is trying to get done by 3/11, and also, in the process hanging
up 1.1, in order to solve the problem of threaded C++ programs using
STL.  That's a good problem to solve.  Unfortunately, in the process,
we broke -ansi programs using STL.  That's a bad problem; STL is
certainly supposed to be ANSI.  Contrary to an opinion voiced
previously on this list, I do use -ansi with C++ programs quite often,
more often than I use threads.

So, Jason's got a fix that, while admittedly a band-aid, makes both
things work.  And, it doesn't require doing any fix-includes like
work.  Let's leave well enough alone, and, perhaps, fix it better in
1.1.  There are a variety of things we might do here; for example,
perhaps with -ansi we shouldn't include pthread.h at all; as Ulrich
pointed out, that's not an ANSI header.

At this point, though, let's go on to something else.

-- 
Mark Mitchell		mmitchell@usa.net
Stanford University	http://www.stanford.edu