> From: Ulrich Weigand <uweig...@de.ibm.com>
> Date: Thu, 8 Oct 2015 18:52:22 +0200
> Hans-Peter Nilsson wrote:
>
> > 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?
>
> I'm not using sys-include, so I don't really have a strong
> opinion on this setup. However, I found this in the docs:
Ow, I didn't look there this time. I've forgotten if I've done
so in the past. If so, it may have been at a time even before
with-sysroot!
> @item --with-headers
> @itemx --with-headers=@var{dir}
> Deprecated in favor of @option{--with-sysroot}.
> Specifies that target headers are available when building a cross compiler.
> The @var{dir} argument specifies a directory which has the target include
> files. These include files will be copied into the @file{gcc} install
> directory. @emph{This option with the @var{dir} argument is required} when
> building a cross compiler, if @file{@var{prefix}/@var{target}/sys-include}
> doesn't pre-exist. If @file{@var{prefix}/@var{target}/sys-include} does
> pre-exist, the @var{dir} argument may be omitted. @command{fixincludes}
> will be run on these files to make them compatible with GCC@.
>
> @item --without-headers
> Tells GCC not use any target headers from a libc when building a cross
> compiler. When crossing to GNU/Linux, you need the headers so GCC
> can build the exception handling for libgcc.
>
> This seems to imply to me that --with-headers without any <dir> argument
> is supposed to use the pre-existing sys-include directory.
Looks like it. But the implementation had another opinion...
> The docs are somewhat silent on what exactly the complete absence of
> both --with-headers and --without-headers means.
It should either be a clear verbose error at configure time or
should work.
> Another potential interpretation might be:
>
> --with-headers=<dir> Copy headers from <dir> to sys-include
> --with-headers Use existing sys-include directory
> <nothing> Same as --with-headers
> --without-headers Do not use any headers
>
> which simplifies the option space, and makes --with/out-headers
> match the behavior of other --with/out- options. It would basically
> require use of sys-include for cross-compilers (which the docs could
> be read to imply anyway, already).
Needless to mention, that's the way I've read it, possibly
because it was the minimum editing distance to the
implementation at the time... :-}
Well, with the exception of "--with-headers" (no argument)
which I, just like the person(s) before me, did not consider.
Sorry.
> > 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...
>
> On the other hand, the current docs appear to imply that the
> intent was for --with-headers (=yes) to look into a pre-existing
> sys-include directory for headers.
Right. So, if you'd prefer to align the implementation with
that, I don't mind. But, these are odd cases as-is, so current
use and users matter when aligning the documentation and
implementation and I wouldn't be surprised if the entire
usage-space is between ours...
> > 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.
>
> So this would be:
>
> --with-headers=<dir> Copy headers from <dir> to sys-include
> --with-headers Use headers from prefix include directory
> <nothing> Use existing sys-include directory
> --without-headers Do not use any headers
>
> I agree that this is the smallest change to current behavior;
> on the other hand, it seems quite odd overall (i.e. hardest to
> explain to someone unfamiliar with current behavior).
Arguably so, a bit unfortunate.
> At the very least, the docs would have to be adapted.
Agreed.
brgds, H-P
