Hans-Peter Nilsson wrote:
> > From: Ulrich Weigand <uweig...@de.ibm.com>
> > Date: Tue, 6 Oct 2015 16:04:35 +0200
>
> > 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.
Well, --with-newlib doesn't really matter here, since the only use in GCC
itself is for this check:
if { { test x$host != x$target && test "x$with_sysroot" = x ; } ||
test x$with_newlib = xyes ; } &&
{ test "x$with_headers" = xno || test ! -f "$target_header_dir/stdio.h"; }
; then
inhibit_libc=true
fi
and since for me host != target and I don't use a sysroot, the first
condition in the || is already true.
(I don't like using --with-newlib because it causes the configure scripts
in the various target libraries to stop doing cross-compile checks and
default to hard-coded assumptions on which functions are and are not
present. Those hard-coded checks tend to be outdated and/or wrong for
SPU; while the ususal cross-compile checks work just fine if newlib has
been installed into the prefix before.)
> > > +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.
Yes, pretty much the only use for --with-headers without argument was to
short-circuit the inhibit_libc test.
> > 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.
So the question is what this should do then? Should I simply add back the
behavior that when using --with-headers, we never get inhibit_libc set?
Or should we simply ignore --with-headers and check for the presence of
headers installed in the prefix? This would work too, once we solve the
sys-include vs. include problem.
Bye,
Ulrich
--
Dr. Ulrich Weigand
GNU/Linux compilers and toolchain
ulrich.weig...@de.ibm.com
