[RFA 1/2]: Don't ignore target_header_dir when deciding inhibit_libc
Hans-Peter Nilsson
hans-peter.nilsson@axis.com
Tue Oct 6 17:28:00 GMT 2015
> From: Ulrich Weigand <uweigand@de.ibm.com>
> Date: Tue, 6 Oct 2015 18:55:53 +0200
> Hans-Peter Nilsson wrote:
>
> > Sanity-check: you do have a $target_header_dir/stdio.h right?
>
> Well, no. That was the point of my original mail :-)
But you apparently have something that *would* fit.
> > Maybe make with_headers=yes (i.e. not a path) have the effect of
> > setting target_header_dir to include instead of sys-include?
(...and inspect both, use the first one that works?)
> That would solve my problem. However, if with_headers is not set at all,
> shouldn't we then *also* set it to include?
Definitely not, only one reason of several being as that'd break
current use.
> I don't really particularly want to use --with-headers, it's just that
> this is what worked in the past. Ideally, it would be best if everything
> just worked as expected without any option if there are indeed already
> headers installed in the prefix.
--enable-dwim? :]
> > 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.
>
> Well, every other use of $target_header_dir does not in fact matter
> on the SPU (because they check for features that aren't present in
> newlib and/or on the SPU anyway). That's why the weird behaviour
> did not really matter in the past ...
>
> So short-circuting just for inhibit_libc would get everything back
> to where we were before your patch. But I agree this is not really
> the right solution.
>
> My preferred solution would be to set $target_header_dir to include
> instead of sys-include, always. I'm just a bit worried if this may
> break other users that have a workflow that somehow works with the
> current setup using sys-include.
(T would: proof of existence here.) I'm more than worried!
Please don't suggest to change a toolchain configuration item
only because you used something that half-way worked, then
broke, like this. Not the least when also saying the below:
> I guess my underlying problem is
> that I don't quite understand how the whole sys-include thing was
> intended to work in the first place ...
I don't know when "include" will work and not, in particular
compared to "sys-include".
> [ Note there's also CROSS_SYSTEM_HEADER_DIR, which is also sometimes
> set to sys-include ... ]
Always, in the absence of sysroot.
brgds, H-P
More information about the Gcc-patches
mailing list