[RFA 1/2]: Don't ignore target_header_dir when deciding inhibit_libc

[Hans-Peter Nilsson]

> From: Ulrich Weigand <uweigand@de.ibm.com>
> Date: Tue, 6 Oct 2015 16:04:35 +0200

> Hans-Peter Nilsson wrote:
> 
> > The directory at $target_header_dir is already inspected in
> > gcc/configure, for e.g. glibc version and stack protector
> > support, but not for setting inhibit_libc.  This is just
> > inconsistent and the obvious resolution to me is to inhibit
> > inhibit_libc when a target *does* "have its own set of headers",
> > to quote the comment above the inhibit_libc setting.  There is
> > nothing in the build log for "make all-gcc" that shows a
> > difference with/without --with-headers, if headers are actually
> > present anyway!
> 
> > gcc:
> > 	* configure.ac (target_header_dir): Move block defining
> > 	this to before the block setting inhibit_libc.
> > 	(inhibit_libc): When considering $with_headers, just
> > 	check it it's explicitly "no".  If not, also check if
> > 	$target_header_dir/stdio.h is present.  If not, set
> > 	inhibit_libc=true.
> > 	* configure: Regenerate.
> 
> This had the effect of breaking all gcov-related tests in my SPU
> builder, since libgcov was stubbed out due to inhibit_libc now
> being set.
> 
> I'm using the build procedure: build initial GCC (--without-headers),
> use it to build newlib, install newlib into prefix, build final GCC
> (--with-headers).  Using this procedure, inihibit_libc used to *not*
> be set in the final GCC build, but now it is.

And not using --with-newlib I think.  Somewhat of a borderline
case, FWIW.

> I'm seeing two issues here:
> 
> > +if test x$host != x$target || test "x$TARGET_SYSTEM_ROOT" != x; then
> > +  if test "x$with_headers" != x; then
> > +    target_header_dir=$with_headers
> 
> In the common case of just using --with-headers, this now sets
> target_header_dir to "yes", which is not particularly useful.

--with-headers without a path to an argument?
Odd but that *should* work.  I see old lines here and there
including *toplevel* configure.ac that refers to that.

> Now I understand that you didn't introduce those lines, and they were already
> wrong before your patch; but after the patch the problem now actually matters.
> Before the patch, I could always use --with-header to say: just assume headers
> are present in the prefix, and everything worked.

At a quick glance and my initial guess there's a missing two or
four lines checking for with_headers=yes.

> This is not a critical problem since I have a work-around: remove --with-headers
> and also manually create a symlink from sys-include to include in the prefix.
> But it would still be nice to avoid having to do the symlink ...

I'd recommend writing a patch handling that "yes".
I know I'm the one "exposing a latent bug" but you're in a much
better position to test it.

brgds, H-P