Re: build failure (from configure patch?)

[Benjamin Kosnik <bkoz at cygnus dot com>]

> Unfortuntely not.  I've been looking closer now; it seems that the
> various wchar-related configure tests are for whether or not wchar.h
> defines certain features; there is no test done solely for whether wchar.h
> even exists.  The former tests fail (corectly), but not for the reason
> that we think.

Yeah. It's a bit ad hoc at the moment. What should be done, probably is:

1. check for wchar.h
2. check for mbstate_t
3. check for WCHAR_MIN, WCHAR_MAX
4. check for WEOF
5. if all the above are affirmative, then enable _GLIBCPP_USE_WCHAR_T

Presently, 5 is only predicated on 4.

> What dies later on is bits/std_cwchar.h, when it has "#include_next
> <wchar.h>" with no surrounding test to see if the #include should be done.

Should be guarded with _GLIBCPP_USE_WCHAR_T I suppose.

> It may well be that this particular Linux box is horked up (I don't admin
> this one, sorry...).  There is no wchar.h anywhere on the system at all
> except for the shadowing header in the libstdc++ sources.  Somebody who
> actually keeps track of wide character concepts (I sure don't) will have
> to tell me if that's normal or broken; whether a missing wchar.h is to
> be expected or not.

Sounds completely broken. But, that's not the point: the point is that if 
we're going to automate wchar_t support as a configure-time process, it 
should be done correctly and even on this broken box, you should not have 
to fight for a clean compile with wchar_t support disabled. 

-benjamin