> From: Ulrich Weigand <uweig...@de.ibm.com>
> Date: Tue, 6 Oct 2015 17:25:20 +0200
> 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:
Hey, you *did* look at it! ;)
> 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.
Sanity-check: you do have a $target_header_dir/stdio.h right?
If you don't, you need to make it set right; $target_header_dir
is very much supposed to be inspectable at that point.
Maybe make with_headers=yes (i.e. not a path) have the effect of
setting target_header_dir to include instead of sys-include?
> (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.)
Yeah, the whole --with-newlib thing is IMHO a hack, except for
the sole purpose of disabling recognition of a newlib directory
within the toplevel directory, one configurable for the target.
> > > > +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?
Well, except for the "never".
> Or should we simply ignore --with-headers and check for the presence of
> headers installed in the prefix?
Um, are those contradicting alternatives? (Don't make me *think*! :)
Anyway, with_headers=yes/no should simply short-circuit an
inspection of $target_header_dir regarding setting inhibit_libc.
I guess. But then again, target_header_dir really needs to be
set usefully for inspection, or else every use of it needs to be
dominated by a with_headers=yes test or something.
> This would work too, once we solve the
> sys-include vs. include problem.
I think *toplevel* configure.ac needs a "yes" check too, that's
all. (Oh wait, it causes a *copy* to the sys-include target
directory, *outside* of make install and not observing $destdir.
That's a problem by itself. Though, I guess we shrug and say
"incidental".)
brgds, H-P
