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

On 09/09/16 15:32, Andre Vieira (lists) wrote: > On 27/05/16 15:51, Ulrich Weigand wrote: >> Andre Vieira (lists) wrote: >>> On 07/04/16 10:30, Andre Vieira (lists) wrote: On 17/03/16 16:33, Andre Vieira (lists) wrote: > On 23/10/15 12:31, Bernd Schmidt wrote: >> On 10/12/2015 11:58

[GCC-6][RFA 1/2]: Don't ignore target_header_dir when deciding inhibit_libc

On 27/05/16 15:51, Ulrich Weigand wrote: > Andre Vieira (lists) wrote: >> On 07/04/16 10:30, Andre Vieira (lists) wrote: >>> On 17/03/16 16:33, Andre Vieira (lists) wrote: On 23/10/15 12:31, Bernd Schmidt wrote: > On 10/12/2015 11:58 AM, Ulrich Weigand wrote: >> >> Index:

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

Andre Vieira (lists) wrote: > On 07/04/16 10:30, Andre Vieira (lists) wrote: > > On 17/03/16 16:33, Andre Vieira (lists) wrote: > >> On 23/10/15 12:31, Bernd Schmidt wrote: > >>> On 10/12/2015 11:58 AM, Ulrich Weigand wrote: > > Index: gcc/configure.ac >

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

On 07/04/16 10:30, Andre Vieira (lists) wrote: > On 17/03/16 16:33, Andre Vieira (lists) wrote: >> On 23/10/15 12:31, Bernd Schmidt wrote: >>> On 10/12/2015 11:58 AM, Ulrich Weigand wrote: Index: gcc/configure.ac ===

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

On 17/03/16 16:33, Andre Vieira (lists) wrote: > On 23/10/15 12:31, Bernd Schmidt wrote: >> On 10/12/2015 11:58 AM, Ulrich Weigand wrote: >>> >>> Index: gcc/configure.ac >>> === >>> --- gcc/configure.ac(revision 228530) >>> +++

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

On 23/10/15 12:31, Bernd Schmidt wrote: > On 10/12/2015 11:58 AM, Ulrich Weigand wrote: >> >> Index: gcc/configure.ac >> === >> --- gcc/configure.ac(revision 228530) >> +++ gcc/configure.ac(working copy) >> @@ -1993,7 +1993,7

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

On 10/12/2015 11:58 AM, Ulrich Weigand wrote: Index: gcc/configure.ac === --- gcc/configure.ac(revision 228530) +++ gcc/configure.ac(working copy) @@ -1993,7 +1993,7 @@ elif test "x$TARGET_SYSTEM_ROOT" != x; t fi if

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

Hans-Peter Nilsson wrote: > > > 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

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

> From: Ulrich Weigand > Date: Mon, 12 Oct 2015 11:58:40 +0200 (cutting *only* because I had a comment; not an indication of preference.) > --or-- > > 2b) Change target_header_dir from a single directory to a list of > directories, and check all of these for header

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

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

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

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

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

Hans-Peter Nilsson wrote: > > > From: Ulrich Weigand > > 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

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

> From: Ulrich Weigand > Date: Wed, 7 Oct 2015 17:32:12 +0200 > Hans-Peter Nilsson wrote: > > > > > From: Ulrich Weigand > > > Date: Tue, 6 Oct 2015 18:55:53 +0200 > > > > > > Maybe make with_headers=yes (i.e. not a path) have the effect of > > > >

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

Hans-Peter Nilsson wrote: > > From: Ulrich Weigand > > Date: Tue, 6 Oct 2015 16:04:35 +0200 > > > I'm using the build procedure: build initial GCC (--without-headers), > > use it to build newlib, install newlib into prefix, build final GCC > > (--with-headers). Using this

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

Hans-Peter Nilsson wrote: > The directory at $target_header_dir is already inspected in > gcc/configure, for e.g. glibc version and stack protector > support, but not for setting inhibit_libc. This is just > inconsistent and the obvious resolution to me is to inhibit > inhibit_libc when a target

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

> From: Ulrich Weigand > Date: Tue, 6 Oct 2015 18:55:53 +0200 > Hans-Peter Nilsson wrote: > > > Sanity-check: you do have a $target_header_dir/stdio.h right? > > Well, no. That was the point of my original mail :-) But you apparently have something that *would* fit. > >

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

> From: Ulrich Weigand > Date: Tue, 6 Oct 2015 17:25:20 +0200 > Hans-Peter Nilsson wrote: > > > From: Ulrich Weigand > > > Date: Tue, 6 Oct 2015 16:04:35 +0200 > > > > > I'm using the build procedure: build initial GCC (--without-headers), > > > use it

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

Hans-Peter Nilsson wrote: > Sanity-check: you do have a $target_header_dir/stdio.h right? Well, no. That was the point of my original mail :-) With my initial configure line, using --with-headers, $target_header_dir is "yes" at this point, and I don't have "yes/stdio.h". Omitting

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

> From: Ulrich Weigand > Date: Tue, 6 Oct 2015 16:04:35 +0200 > Hans-Peter Nilsson wrote: > > > The directory at $target_header_dir is already inspected in > > gcc/configure, for e.g. glibc version and stack protector > > support, but not for setting inhibit_libc. This is

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

Hi! On Thu, 4 Sep 2014 23:40:40 +0200, Hans-Peter Nilsson hans-peter.nils...@axis.com wrote: The directory at $target_header_dir is [...] gcc: * configure.ac (target_header_dir): Move block defining this to before the block setting inhibit_libc. (inhibit_libc): When

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

From: Thomas Schwinge tho...@codesourcery.com Date: Tue, 23 Sep 2014 23:21:05 +0200 Hi! On Thu, 4 Sep 2014 23:40:40 +0200, Hans-Peter Nilsson hans-peter.nilsson@a= xis.com wrote: The directory at $target_header_dir is [...] gcc: * configure.ac (target_header_dir): Move block

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

On 09/12/14 11:49, Hans-Peter Nilsson wrote: Ping! http://gcc.gnu.org/ml/gcc-patches/2014-09/msg00402.html From: Hans-Peter Nilsson h...@axis.com Date: Thu, 4 Sep 2014 23:40:40 +0200 The directory at $target_header_dir is already inspected in gcc/configure, for e.g. glibc version and stack

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

Ping! http://gcc.gnu.org/ml/gcc-patches/2014-09/msg00402.html From: Hans-Peter Nilsson h...@axis.com Date: Thu, 4 Sep 2014 23:40:40 +0200 The directory at $target_header_dir is already inspected in gcc/configure, for e.g. glibc version and stack protector support, but not for setting

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

The directory at $target_header_dir is already inspected in gcc/configure, for e.g. glibc version and stack protector support, but not for setting inhibit_libc. This is just inconsistent and the obvious resolution to me is to inhibit inhibit_libc when a target *does* have its own set of headers,