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.
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.
> + elif test "x$with_sysroot" = x; then
> +
> target_header_dir="${test_exec_prefix}/${target_noncanonical}/sys-include"
If I change my build procedure to omit --with-headers, it still won't find the
headers since newlib install placed them into .../include, not .../sys-include.
The whole sys-include thing has always confused me anyway :-) I thought that
the point of sys-include is that if you specify --with-headers=<dir>, then
the contents of <dir> will be copied into your prefix under .../sys-include;
the compiler will use both .../sys-include *and* .../include, using the
former to find headers specified using --with-headers, and the latter to
find headers already installed in the prefix.
While the compiler will search both locations, target_header_dir can only be
set to one of them. However, in this case, it seems it would be more useful
to set it to .../include: since .../sys-include should only ever contain
anything when using --with-headers=<dir>, and in *that* case, target_header_dir
is being set directly to <dir> anyway.
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.
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 ...
Bye,
Ulrich
--
Dr. Ulrich Weigand
GNU/Linux compilers and toolchain
[email protected]
