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:
@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.
The docs are somewhat silent on what exactly the complete absence of
both --with-headers and --without-headers means.
One potential interpretation might be:
--with-headers=<dir> Copy headers from <dir> to sys-include
--with-headers Use existing sys-include directory
<nothing> Use headers from prefix include directory
--without-headers Do not use any headers
which would at least make it clear that if you want sys-include,
you need to specify --with-headers ...
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).
> > 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>).
OK, I see.
> > 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.
Agreed with everything here so far.
> 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.
> > 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.
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). At the
very least, the docs would have to be adapted.
Bye,
Ulrich
--
Dr. Ulrich Weigand
GNU/Linux compilers and toolchain
ulrich.weig...@de.ibm.com
