Re: New build breakage on 3.0 branch

[Phil Edwards <pedwards at disaster dot jaj dot com>]

On Thu, Mar 01, 2001 at 03:27:27PM -0600, Robert Lipe wrote:
> > > Thanx for the reply.  (I miss the old days when 'configure ... --recheck'
> > > would do the right thing...)
> > 
> > It still does, but not for the target directory.  I have to blow away the
> > whole cpu-vendor-os dir, and then, of course, the recheck isn't recursive
> 
> Then it doesn't do the right thing, thing does it? :-)

It does the right thing for the the immediate subdirs, which is all that
most people care about.  :-)  I think if the --norecursion flag got axed
it would work even without removing the targetdir, but that's a guess.
(I never really saw the point of disabling recursion on a reconfigure.)


> I think you're asking me where the lib*v3/include/bits/* links are
> pointing, right?  (You have to type slowly for me.)  The answer to that
> question is "generic".

My bad; it's not the OS configury bits that do this.  It's the choice of
C headers.  What are _GLIBCPP_HAVE_MBSTATE_T and _GLIBCPP_HAVE_WCHAR_H
in your generated include/bits/c++config.h, and C_INCLUDE_DIR in the
generated Makefile?

We're about to fall off the edge of my knowledge of the C shadowing headers,
which are being worked on regularly anyhow...


Phil

-- 
pedwards at disaster dot jaj dot com  |  pme at sources dot redhat dot com
devphil at several other less interesting addresses in various dot domains
The gods do not protect fools.  Fools are protected by more capable fools.