> From: Ulrich Weigand <uweig...@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
