Re: build system: gcc_cv_libc_provides_ssp and NATIVE_SYSTEM_HEADER_DIR

[Thomas Schwinge]

Hello!

On Thu, Oct 09, 2008 at 11:49:06AM +0200, Paolo Bonzini wrote:
> > Unfortunately, NATIVE_SYSTEM_HEADER_DIR is a Makefile variable (see
> > gcc/config/t-gnu).  It is being used only in three places:
> > gcc/config/t-gnu, gcc/config/t-gnu and gcc/config/i386/t-mingw32.  What

That list was bogus, of course.  Here's the correct list:

    gcc/config/t-gnu:NATIVE_SYSTEM_HEADER_DIR = /include
    gcc/config/i386/t-mingw32:NATIVE_SYSTEM_HEADER_DIR = /mingw/include
    gcc/config/i386/t-djgpp:NATIVE_SYSTEM_HEADER_DIR=$(DJDIR)/include

> > do you suggest?  Make that definition a shell variable and move it to
> > gcc/config.gcc?
> 
> I see your point, but what about not making "/usr a four letter word" in
> GNU? :-)

It wasn't me who decided this speciality (nor do I repudiate it).

Nevertheless, resorting to doing this (have N_S_H_D as well be
/usr/include for GNU/Hurd) would be missing the chance to implement a
proper technical solution, i.e., removing the (ugly, IMO) hard-coded
$SYSROOT/usr/include paths from configure.ac.  :-)

Ideally, IMO, this test (for stack-smashing-protection support in glibc)
should not be done by grepping through SYSROOT's features.h, but instead
by using the CPP for doing that.  The problem is that CPP has not yet
been bulit at the place where the test is currently been done (in GCC's
configure).  I don't see how this could be done, even, as the CPP and the
code-generation backend, which needs to know about SSP support in glibc,
are entangled to much.  Or can it be done this way?


Regards,
 Thomas

signature.asc
Description: Digital signature