> From: Ulrich Weigand <uweig...@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
