$prefix/lib/../$target/sys-include not in <> search path

$prefix/lib/../$target/sys-include not in <> search path

[Hans-Peter Nilsson]

When configured with just a --prefix=x and --target=y,
$prefix/lib/../$target/sys-include used to be searched, for e.g.
limits.h, stdio.h and stdlib.h.  No $prefix-rooted path shows
up as a "ignoring nonexistent directory" message either.

I don't know when this changed, but it doesn't seem like a
deliberate change.  Or at least, not an improvement.

I'll open a PR if I can't resolve this.

brgds, H-P

Re: $prefix/lib/../$target/sys-include not in <> search path

[Hans-Peter Nilsson]

On Mon, 10 Dec 2007, Hans-Peter Nilsson wrote:
> When configured with just a --prefix=x and --target=y,
> $prefix/lib/../$target/sys-include used to be searched, for e.g.
> limits.h, stdio.h and stdlib.h.  No $prefix-rooted path shows
> up as a "ignoring nonexistent directory" message either.
>
> I don't know when this changed, but it doesn't seem like a
> deliberate change.  Or at least, not an improvement.
>
> I'll open a PR if I can't resolve this.

I wouldn't call it a resolution, but it seems an installed
toolchain will work.  Equivalently:
 mkdir -p $prefix/lib/gcc/$target/$gcc_version e.g.
 mkdir -p $prefix/lib/gcc/cris-axis-linux-gnu/4.3.0
should let gcc find $prefix/sys-include, because it wants to go
back and forth:
 $prefix/lib/gcc/cris-axis-linux-gnu/4.3.0/../../../../cris-axis-linux-gnu/sys-include

IIRC it used to be this bad, then something or other changed to
let it find $prefix/sys-include without the intermediate
directories, and now it's bad again.  (Bad in that I have to
write into $prefix in order to test, and have to keep a
$gcc_version directory there.)

Or perhaps better hack the testsuite to add a -idirafter or
something.  Suggestions welcome.  Except "use buildroot" (not
even sure it'd help).

brgds, H-P