> From: Ulrich Weigand <uweig...@de.ibm.com> > Date: Wed, 7 Oct 2015 17:32:12 +0200
> Hans-Peter Nilsson wrote: > > > > > From: Ulrich Weigand <uweig...@de.ibm.com> > > > Date: Tue, 6 Oct 2015 18:55:53 +0200 > > > > > > 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?) > > So what does "works" mean, here? Do you expect that all headers are > present either in include or all in sys-include? Or is there a > scenario where some headers may be in either directory, and you'd > have to check separately for any header you want to access? *I* don't know. Perhaps? I don't have that setup. Let me ask you right back: after an installation, should installation of a newer gcc *not* automatically pick up the header files installed (copied to sys-include) by the previous installation when using the same prefix, *without* any --with-headers specified in the new configury? > > > 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". > > So I wondering: what is your current setup? What headers do you have > in sys-include, and how did they get there? In the setup we're talking about, they're all in sys-include, copied "manually" before anything else (IIUC just like what would happen if I had the headers elsewhere and specified a --with-headers=<path>). > I'm aware of the copying > done when using --with-headers=<dir>, but this case should still work, > since $target_header_dir is set directly to <dir> in this case anyway. Eh... I'm easily confused. Let me recap my understanding: now, with --with-headers=<path>, we copy from <dir> to sys-include and still look in (where "look in" means target_header_dir is set to and gcc configury inspects) <dir> at configury-time and the built gcc will look in include *and* sys-include. Without --with-headers (at all), configury looks in sys-include. With --with-headers (=yes) things are (currently as well as before, just not as exposed) broken; we try and look in "yes". The recentish (it's only been a year :) exposure being that inhibit_libc is *also* activated, as configury sanity-check can't find a basic header file. That sanity-check itself *is* sane; gcc header inspection should be able to find whatever headers are specified or the default; it's just that the value is broken. I think it's wrong to be ok that the current header tests don't matter for your target. So, ISTM we should change --with-headers (=yes) to either look in sys-include or in include. Setting it to sys-include wouldn't help you or anyone else as it's already the default... > Is there some *other* case, where you do not use --with-headers=<dir>, > but still have a pre-existing sys-include directory in the prefix? (Eh, other than pre-existing?) Headers are pre-installed in sys-include. No --with-headers options. GCC looks in sys-include by default, both at configury-time and when built. Me happy. To wit, I think having with_headers=yes (i.e. not a path) have the effect of setting target_header_dir to include instead of sys-include would be the least evil, least unexpected change, that would work for most, including you. I wouldn't understand to instead change things around and make "include" be inspected by default. It's only the --with-headers option that's broken. brgds, H-P
