Re: [RFA 1/2]: Don't ignore target_header_dir when deciding inhibit_libc

[Hans-Peter Nilsson <hans-peter dot nilsson at axis dot com>]

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