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

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

[Hans-Peter Nilsson]

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",
to quote the comment above the inhibit_libc setting.  There is
nothing in the build log for "make all-gcc" that shows a
difference with/without --with-headers, if headers are actually
present anyway!

It may seem that libgcc/configure.ac would be the appropriate
place to patch and test, but it is gcc/configure.ac which tests
various things about target headers and makes the inhibit_libc
decision, exporting it through the generated obj/gcc/libgcc.mvars
that is included in libgcc/Makefile.

Tested before/after by "make all-gcc" on native x86_64-linux (*a) and
seeing it still set (for the peace of most users) in
gcc/Makefile, and cross to mipsel-linux "make all-gcc" with/without (*b,c) a
pre-installed set of headers just implied by --prefix and --target to
observe the intended difference and the same with (*d)
--with-sysroot (but no headers at the sysroot) and (*e)
--with-build-sysroot and both (*f) (note that
--with-build-sysroot=... without --with-sysroot also got
inhibit_libc) to observe no change for the --with-sysroot one
(still no inhibit_libc).  The same with --with-headers
(*g). Also, I checked that nothing other than the inhibit_libc code
uses target_header_dir or sets the used variables in the block
of code involved in the move.

Ok to commit?

gcc:
	* configure.ac (target_header_dir): Move block defining
	this to before the block setting inhibit_libc.
	(inhibit_libc): When considering $with_headers, just
	check it it's explicitly "no".  If not, also check if
	$target_header_dir/stdio.h is present.  If not, set
	inhibit_libc=true.
	* configure: Regenerate.

Index: gcc/configure.ac
===================================================================
--- gcc/configure.ac	(revision 214736)
+++ gcc/configure.ac	(working copy)
@@ -1924,6 +1924,22 @@ elif test "x$TARGET_SYSTEM_ROOT" != x; t
         SYSTEM_HEADER_DIR=$build_system_header_dir 
 fi
 
+if test x$host != x$target || test "x$TARGET_SYSTEM_ROOT" != x; then
+  if test "x$with_headers" != x; then
+    target_header_dir=$with_headers
+  elif test "x$with_sysroot" = x; then
+    target_header_dir="${test_exec_prefix}/${target_noncanonical}/sys-include"
+  elif test "x$with_build_sysroot" != "x"; then
+    target_header_dir="${with_build_sysroot}${native_system_header_dir}"
+  elif test "x$with_sysroot" = xyes; then
+    target_header_dir="${test_exec_prefix}/${target_noncanonical}/sys-root${native_system_header_dir}"
+  else
+    target_header_dir="${with_sysroot}${native_system_header_dir}"
+  fi
+else
+  target_header_dir=${native_system_header_dir}
+fi
+
 # If this is a cross-compiler that does not
 # have its own set of headers then define
 # inhibit_libc
@@ -1935,7 +1951,7 @@ fi
 : ${inhibit_libc=false}
 if { { test x$host != x$target && test "x$with_sysroot" = x ; } ||
        test x$with_newlib = xyes ; } &&
-     { test "x$with_headers" = x || test "x$with_headers" = xno ; } ; then
+     { test "x$with_headers" = xno || test ! -f "$target_header_dir/stdio.h"; } ; then
        inhibit_libc=true
 fi
 AC_SUBST(inhibit_libc)
@@ -4441,22 +4457,6 @@ if test x$with_sysroot = x && test x$hos
    && test "$prefix" != "NONE"; then
   AC_DEFINE_UNQUOTED(PREFIX_INCLUDE_DIR, "$prefix/include",
 [Define to PREFIX/include if cpp should also search that directory.])
-fi
-
-if test x$host != x$target || test "x$TARGET_SYSTEM_ROOT" != x; then
-  if test "x$with_headers" != x; then
-    target_header_dir=$with_headers
-  elif test "x$with_sysroot" = x; then
-    target_header_dir="${test_exec_prefix}/${target_noncanonical}/sys-include"
-  elif test "x$with_build_sysroot" != "x"; then
-    target_header_dir="${with_build_sysroot}${native_system_header_dir}"
-  elif test "x$with_sysroot" = xyes; then
-    target_header_dir="${test_exec_prefix}/${target_noncanonical}/sys-root${native_system_header_dir}"
-  else
-    target_header_dir="${with_sysroot}${native_system_header_dir}"
-  fi
-else
-  target_header_dir=${native_system_header_dir}
 fi
 
 # Determine the version of glibc, if any, used on the target.

brgds, H-P

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

[Hans-Peter Nilsson]

Ping! <http://gcc.gnu.org/ml/gcc-patches/2014-09/msg00402.html>

> From: Hans-Peter Nilsson <hp@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 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",
> to quote the comment above the inhibit_libc setting.  There is
> nothing in the build log for "make all-gcc" that shows a
> difference with/without --with-headers, if headers are actually
> present anyway!
> 
> It may seem that libgcc/configure.ac would be the appropriate
> place to patch and test, but it is gcc/configure.ac which tests
> various things about target headers and makes the inhibit_libc
> decision, exporting it through the generated obj/gcc/libgcc.mvars
> that is included in libgcc/Makefile.
> 
> Tested before/after by "make all-gcc" on native x86_64-linux (*a) and
> seeing it still set (for the peace of most users) in
> gcc/Makefile, and cross to mipsel-linux "make all-gcc" with/without (*b,c) a
> pre-installed set of headers just implied by --prefix and --target to
> observe the intended difference and the same with (*d)
> --with-sysroot (but no headers at the sysroot) and (*e)
> --with-build-sysroot and both (*f) (note that
> --with-build-sysroot=... without --with-sysroot also got
> inhibit_libc) to observe no change for the --with-sysroot one
> (still no inhibit_libc).  The same with --with-headers
> (*g). Also, I checked that nothing other than the inhibit_libc code
> uses target_header_dir or sets the used variables in the block
> of code involved in the move.
> 
> Ok to commit?
> 
> gcc:
> 	* configure.ac (target_header_dir): Move block defining
> 	this to before the block setting inhibit_libc.
> 	(inhibit_libc): When considering $with_headers, just
> 	check it it's explicitly "no".  If not, also check if
> 	$target_header_dir/stdio.h is present.  If not, set
> 	inhibit_libc=true.
> 	* configure: Regenerate.
> 
> Index: gcc/configure.ac
> ===================================================================
> --- gcc/configure.ac	(revision 214736)
> +++ gcc/configure.ac	(working copy)
> @@ -1924,6 +1924,22 @@ elif test "x$TARGET_SYSTEM_ROOT" != x; t
>          SYSTEM_HEADER_DIR=$build_system_header_dir 
>  fi
>  
> +if test x$host != x$target || test "x$TARGET_SYSTEM_ROOT" != x; then
> +  if test "x$with_headers" != x; then
> +    target_header_dir=$with_headers
> +  elif test "x$with_sysroot" = x; then
> +    target_header_dir="${test_exec_prefix}/${target_noncanonical}/sys-include"
> +  elif test "x$with_build_sysroot" != "x"; then
> +    target_header_dir="${with_build_sysroot}${native_system_header_dir}"
> +  elif test "x$with_sysroot" = xyes; then
> +    target_header_dir="${test_exec_prefix}/${target_noncanonical}/sys-root${native_system_header_dir}"
> +  else
> +    target_header_dir="${with_sysroot}${native_system_header_dir}"
> +  fi
> +else
> +  target_header_dir=${native_system_header_dir}
> +fi
> +
>  # If this is a cross-compiler that does not
>  # have its own set of headers then define
>  # inhibit_libc
> @@ -1935,7 +1951,7 @@ fi
>  : ${inhibit_libc=false}
>  if { { test x$host != x$target && test "x$with_sysroot" = x ; } ||
>         test x$with_newlib = xyes ; } &&
> -     { test "x$with_headers" = x || test "x$with_headers" = xno ; } ; then
> +     { test "x$with_headers" = xno || test ! -f "$target_header_dir/stdio.h"; } ; then
>         inhibit_libc=true
>  fi
>  AC_SUBST(inhibit_libc)
> @@ -4441,22 +4457,6 @@ if test x$with_sysroot = x && test x$hos
>     && test "$prefix" != "NONE"; then
>    AC_DEFINE_UNQUOTED(PREFIX_INCLUDE_DIR, "$prefix/include",
>  [Define to PREFIX/include if cpp should also search that directory.])
> -fi
> -
> -if test x$host != x$target || test "x$TARGET_SYSTEM_ROOT" != x; then
> -  if test "x$with_headers" != x; then
> -    target_header_dir=$with_headers
> -  elif test "x$with_sysroot" = x; then
> -    target_header_dir="${test_exec_prefix}/${target_noncanonical}/sys-include"
> -  elif test "x$with_build_sysroot" != "x"; then
> -    target_header_dir="${with_build_sysroot}${native_system_header_dir}"
> -  elif test "x$with_sysroot" = xyes; then
> -    target_header_dir="${test_exec_prefix}/${target_noncanonical}/sys-root${native_system_header_dir}"
> -  else
> -    target_header_dir="${with_sysroot}${native_system_header_dir}"
> -  fi
> -else
> -  target_header_dir=${native_system_header_dir}
>  fi
>  
>  # Determine the version of glibc, if any, used on the target.
> 
> brgds, H-P
> 

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

[Jeff Law]

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 <hp@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 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",
>> to quote the comment above the inhibit_libc setting.  There is
>> nothing in the build log for "make all-gcc" that shows a
>> difference with/without --with-headers, if headers are actually
>> present anyway!
>>
>> It may seem that libgcc/configure.ac would be the appropriate
>> place to patch and test, but it is gcc/configure.ac which tests
>> various things about target headers and makes the inhibit_libc
>> decision, exporting it through the generated obj/gcc/libgcc.mvars
>> that is included in libgcc/Makefile.
>>
>> Tested before/after by "make all-gcc" on native x86_64-linux (*a) and
>> seeing it still set (for the peace of most users) in
>> gcc/Makefile, and cross to mipsel-linux "make all-gcc" with/without (*b,c) a
>> pre-installed set of headers just implied by --prefix and --target to
>> observe the intended difference and the same with (*d)
>> --with-sysroot (but no headers at the sysroot) and (*e)
>> --with-build-sysroot and both (*f) (note that
>> --with-build-sysroot=... without --with-sysroot also got
>> inhibit_libc) to observe no change for the --with-sysroot one
>> (still no inhibit_libc).  The same with --with-headers
>> (*g). Also, I checked that nothing other than the inhibit_libc code
>> uses target_header_dir or sets the used variables in the block
>> of code involved in the move.
>>
>> Ok to commit?
>>
>> gcc:
>> 	* configure.ac (target_header_dir): Move block defining
>> 	this to before the block setting inhibit_libc.
>> 	(inhibit_libc): When considering $with_headers, just
>> 	check it it's explicitly "no".  If not, also check if
>> 	$target_header_dir/stdio.h is present.  If not, set
>> 	inhibit_libc=true.
>> 	* configure: Regenerate.
OK.
jeff

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

[Thomas Schwinge]

[-- Attachment #1: Type: text/plain, Size: 3370 bytes --]

Hi!

On Thu, 4 Sep 2014 23:40:40 +0200, Hans-Peter Nilsson <hans-peter.nilsson@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 considering $with_headers, just
> 	check it it's explicitly "no".  If not, also check if
> 	$target_header_dir/stdio.h is present.  If not, set
> 	inhibit_libc=true.
> 	* configure: Regenerate.

This got committed as r215439.  In r215532 I just put the following on
top -- perhaps your tree was "dirty" some way or another when you
regenerated gcc/configure?

commit 5bf45fadf3e45d4feb74472862a2fbe7917869b8
Author: tschwinge <tschwinge@138bc75d-0d04-0410-961f-82ee72b054a4>
Date:   Tue Sep 23 21:15:36 2014 +0000

    Properly regenerate gcc/configure.
    
    	gcc/
    	* configure: Regenerate.
    
    git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/trunk@215532 138bc75d-0d04-0410-961f-82ee72b054a4
---
 gcc/ChangeLog |  4 ++++
 gcc/configure | 32 ++------------------------------
 2 files changed, 6 insertions(+), 30 deletions(-)

diff --git gcc/ChangeLog gcc/ChangeLog
index 651497d..f2b7b2d 100644
--- gcc/ChangeLog
+++ gcc/ChangeLog
@@ -1,3 +1,7 @@
+2014-09-23  Thomas Schwinge  <thomas@codesourcery.com>
+
+	* configure: Regenerate.
+
 2014-09-23  Alan Lawrence  <alan.lawrence@arm.com>
 
 	* combine.c (simplify_shift_const_1): Allow commuting (ashiftrt (xor))
diff --git gcc/configure gcc/configure
index 32e8094..380a235 100755
--- gcc/configure
+++ gcc/configure
@@ -6607,35 +6607,7 @@ fi
 if test $enable_werror_always = yes; then :
   strict_warn="$strict_warn${strict_warn:+ }-Werror"
 fi
- if test "xmanual" != xmanual; then :
-    { $as_echo "$as_me:${as_lineno-$LINENO}: checking whether $CC is GCC >=manual" >&5
-$as_echo_n "checking whether $CC is GCC >=manual... " >&6; }
-if test "${acx_cv_prog_cc_gcc_manual_or_newer+set}" = set; then :
-  $as_echo_n "(cached) " >&6
-else
-  set fnord `echo manual | tr '.' ' '`
-     shift
-     cat confdefs.h - <<_ACEOF >conftest.$ac_ext
-/* end confdefs.h.  */
-#if __GNUC__ * 10000 + __GNUC_MINOR__ * 100 + __GNUC_PATCHLEVEL__ \
-  < $1 * 10000 + $2 * 100 + $3
-#error insufficient
-#endif
-_ACEOF
-if ac_fn_c_try_cpp "$LINENO"; then :
-  acx_cv_prog_cc_gcc_manual_or_newer=yes
-else
-  acx_cv_prog_cc_gcc_manual_or_newer=no
-fi
-rm -f conftest.err conftest.$ac_ext
-fi
-{ $as_echo "$as_me:${as_lineno-$LINENO}: result: $acx_cv_prog_cc_gcc_manual_or_newer" >&5
-$as_echo "$acx_cv_prog_cc_gcc_manual_or_newer" >&6; }
- if test $acx_cv_prog_cc_gcc_manual_or_newer = yes; then :
-  strict_warn="$strict_warn${strict_warn:+ }-Werror"
-fi
 
-fi
 
 
 # The above macros do nothing if the compiler is not GCC.  However, the
@@ -18077,7 +18049,7 @@ else
   lt_dlunknown=0; lt_dlno_uscore=1; lt_dlneed_uscore=2
   lt_status=$lt_dlunknown
   cat > conftest.$ac_ext <<_LT_EOF
-#line 18080 "configure"
+#line 18052 "configure"
 #include "confdefs.h"
 
 #if HAVE_DLFCN_H
@@ -18183,7 +18155,7 @@ else
   lt_dlunknown=0; lt_dlno_uscore=1; lt_dlneed_uscore=2
   lt_status=$lt_dlunknown
   cat > conftest.$ac_ext <<_LT_EOF
-#line 18186 "configure"
+#line 18158 "configure"
 #include "confdefs.h"
 
 #if HAVE_DLFCN_H


Grüße,
 Thomas

[-- Attachment #2: Type: application/pgp-signature, Size: 472 bytes --]

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

[Hans-Peter Nilsson]

> From: Thomas Schwinge <thomas@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 defining
> > 	this to before the block setting inhibit_libc.
> > 	(inhibit_libc): When considering $with_headers, just
> > 	check it it's explicitly "no".  If not, also check if
> > 	$target_header_dir/stdio.h is present.  If not, set
> > 	inhibit_libc=3Dtrue.
> > 	* configure: Regenerate.
> 
> This got committed as r215439.  In r215532 I just put the following on
> top -- perhaps your tree was "dirty" some way or another when you
> regenerated gcc/configure?

Yep; there was old cruft from a previous patch in the
supposedly-regenerated configure, I missed to actually
regenerate.  Thanks for fixing it.

brgds, H-P

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

[Ulrich Weigand]

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 *does* "have its own set of headers",
> to quote the comment above the inhibit_libc setting.  There is
> nothing in the build log for "make all-gcc" that shows a
> difference with/without --with-headers, if headers are actually
> present anyway!

> gcc:
> 	* configure.ac (target_header_dir): Move block defining
> 	this to before the block setting inhibit_libc.
> 	(inhibit_libc): When considering $with_headers, just
> 	check it it's explicitly "no".  If not, also check if
> 	$target_header_dir/stdio.h is present.  If not, set
> 	inhibit_libc=true.
> 	* configure: Regenerate.

This had the effect of breaking all gcov-related tests in my SPU
builder, since libgcov was stubbed out due to inhibit_libc now
being set.

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 procedure, inihibit_libc used to *not*
be set in the final GCC build, but now it is.

I'm seeing two issues here:

> +if test x$host != x$target || test "x$TARGET_SYSTEM_ROOT" != x; then
> +  if test "x$with_headers" != x; then
> +    target_header_dir=$with_headers

In the common case of just using --with-headers, this now sets
target_header_dir to "yes", which is not particularly useful.

> +  elif test "x$with_sysroot" = x; then
> +    target_header_dir="${test_exec_prefix}/${target_noncanonical}/sys-include"

If I change my build procedure to omit --with-headers, it still won't find the
headers since newlib install placed them into .../include, not .../sys-include.

The whole sys-include thing has always confused me anyway :-)  I thought that
the point of sys-include is that if you specify --with-headers=<dir>, then
the contents of <dir> will be copied into your prefix under .../sys-include;
the compiler will use both .../sys-include *and* .../include, using the
former to find headers specified using --with-headers, and the latter to
find headers already installed in the prefix.

While the compiler will search both locations, target_header_dir can only be
set to one of them.  However, in this case, it seems it would be more useful
to set it to .../include: since .../sys-include should only ever contain
anything when using --with-headers=<dir>, and in *that* case, target_header_dir
is being set directly to <dir> anyway.

Now I understand that you didn't introduce those lines, and they were already
wrong before your patch; but after the patch the problem now actually matters.
Before the patch, I could always use --with-header to say: just assume headers
are present in the prefix, and everything worked.

This is not a critical problem since I have a work-around: remove --with-headers
and also manually create a symlink from sys-include to include in the prefix.
But it would still be nice to avoid having to do the symlink ...

Bye,
Ulrich

-- 
  Dr. Ulrich Weigand
  GNU/Linux compilers and toolchain
  Ulrich.Weigand@de.ibm.com

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

[Hans-Peter Nilsson]

> From: Ulrich Weigand <uweigand@de.ibm.com>
> 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 just
> > inconsistent and the obvious resolution to me is to inhibit
> > inhibit_libc when a target *does* "have its own set of headers",
> > to quote the comment above the inhibit_libc setting.  There is
> > nothing in the build log for "make all-gcc" that shows a
> > difference with/without --with-headers, if headers are actually
> > present anyway!
> 
> > gcc:
> > 	* configure.ac (target_header_dir): Move block defining
> > 	this to before the block setting inhibit_libc.
> > 	(inhibit_libc): When considering $with_headers, just
> > 	check it it's explicitly "no".  If not, also check if
> > 	$target_header_dir/stdio.h is present.  If not, set
> > 	inhibit_libc=true.
> > 	* configure: Regenerate.
> 
> This had the effect of breaking all gcov-related tests in my SPU
> builder, since libgcov was stubbed out due to inhibit_libc now
> being set.
> 
> 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 procedure, inihibit_libc used to *not*
> be set in the final GCC build, but now it is.

And not using --with-newlib I think.  Somewhat of a borderline
case, FWIW.

> I'm seeing two issues here:
> 
> > +if test x$host != x$target || test "x$TARGET_SYSTEM_ROOT" != x; then
> > +  if test "x$with_headers" != x; then
> > +    target_header_dir=$with_headers
> 
> In the common case of just using --with-headers, this now sets
> target_header_dir to "yes", which is not particularly useful.

--with-headers without a path to an argument?
Odd but that *should* work.  I see old lines here and there
including *toplevel* configure.ac that refers to that.

> Now I understand that you didn't introduce those lines, and they were already
> wrong before your patch; but after the patch the problem now actually matters.
> Before the patch, I could always use --with-header to say: just assume headers
> are present in the prefix, and everything worked.

At a quick glance and my initial guess there's a missing two or
four lines checking for with_headers=yes.

> This is not a critical problem since I have a work-around: remove --with-headers
> and also manually create a symlink from sys-include to include in the prefix.
> But it would still be nice to avoid having to do the symlink ...

I'd recommend writing a patch handling that "yes".
I know I'm the one "exposing a latent bug" but you're in a much
better position to test it.

brgds, H-P

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

[Ulrich Weigand]

Hans-Peter Nilsson wrote:
> > From: Ulrich Weigand <uweigand@de.ibm.com>
> > 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 procedure, inihibit_libc used to *not*
> > be set in the final GCC build, but now it is.
> 
> And not using --with-newlib I think.  Somewhat of a borderline
> case, FWIW.

Well, --with-newlib doesn't really matter here, since the only use in GCC
itself is for this check:

if { { test x$host != x$target && test "x$with_sysroot" = x ; } ||
       test x$with_newlib = xyes ; } &&
     { test "x$with_headers" = xno || test ! -f "$target_header_dir/stdio.h"; } ; then
       inhibit_libc=true
fi

and since for me host != target and I don't use a sysroot, the first
condition in the || is already true.

(I don't like using --with-newlib because it causes the configure scripts
in the various target libraries to stop doing cross-compile checks and
default to hard-coded assumptions on which functions are and are not
present.  Those hard-coded checks tend to be outdated and/or wrong for
SPU; while the ususal cross-compile checks work just fine if newlib has
been installed into the prefix before.)

> > > +if test x$host != x$target || test "x$TARGET_SYSTEM_ROOT" != x; then
> > > +  if test "x$with_headers" != x; then
> > > +    target_header_dir=$with_headers
> > 
> > In the common case of just using --with-headers, this now sets
> > target_header_dir to "yes", which is not particularly useful.
> 
> --with-headers without a path to an argument?
> Odd but that *should* work.  I see old lines here and there
> including *toplevel* configure.ac that refers to that.

Yes, pretty much the only use for --with-headers without argument was to
short-circuit the inhibit_libc test.

> > Now I understand that you didn't introduce those lines, and they were already
> > wrong before your patch; but after the patch the problem now actually matters.
> > Before the patch, I could always use --with-header to say: just assume headers
> > are present in the prefix, and everything worked.
> 
> At a quick glance and my initial guess there's a missing two or
> four lines checking for with_headers=yes.
> 
> > This is not a critical problem since I have a work-around: remove --with-headers
> > and also manually create a symlink from sys-include to include in the prefix.
> > But it would still be nice to avoid having to do the symlink ...
> 
> I'd recommend writing a patch handling that "yes".
> I know I'm the one "exposing a latent bug" but you're in a much
> better position to test it.

So the question is what this should do then?  Should I simply add back the
behavior that when using --with-headers, we never get inhibit_libc set?

Or should we simply ignore --with-headers and check for the presence of
headers installed in the prefix?  This would work too, once we solve the
sys-include vs. include problem.

Bye,
Ulrich

-- 
  Dr. Ulrich Weigand
  GNU/Linux compilers and toolchain
  Ulrich.Weigand@de.ibm.com

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

[Hans-Peter Nilsson]

> From: Ulrich Weigand <uweigand@de.ibm.com>
> Date: Tue, 6 Oct 2015 17:25:20 +0200

> Hans-Peter Nilsson wrote:
> > > From: Ulrich Weigand <uweigand@de.ibm.com>
> > > 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 procedure, inihibit_libc used to *not*
> > > be set in the final GCC build, but now it is.
> > 
> > And not using --with-newlib I think.  Somewhat of a borderline
> > case, FWIW.
> 
> Well, --with-newlib doesn't really matter here, since the only use in GCC
> itself is for this check:

Hey, you *did* look at it! ;)

> if { { test x$host != x$target && test "x$with_sysroot" = x ; } ||
>        test x$with_newlib = xyes ; } &&
>      { test "x$with_headers" = xno || test ! -f "$target_header_dir/stdio.h"; } ; then
>        inhibit_libc=true
> fi
> 
> and since for me host != target and I don't use a sysroot, the first
> condition in the || is already true.

Sanity-check: you do have a $target_header_dir/stdio.h right?
If you don't, you need to make it set right; $target_header_dir
is very much supposed to be inspectable at that point.

Maybe make with_headers=yes (i.e. not a path) have the effect of
setting target_header_dir to include instead of sys-include?

> (I don't like using --with-newlib because it causes the configure scripts
> in the various target libraries to stop doing cross-compile checks and
> default to hard-coded assumptions on which functions are and are not
> present.  Those hard-coded checks tend to be outdated and/or wrong for
> SPU; while the ususal cross-compile checks work just fine if newlib has
> been installed into the prefix before.)

Yeah, the whole --with-newlib thing is IMHO a hack, except for
the sole purpose of disabling recognition of a newlib directory
within the toplevel directory, one configurable for the target.

> > > > +if test x$host != x$target || test "x$TARGET_SYSTEM_ROOT" != x; then
> > > > +  if test "x$with_headers" != x; then
> > > > +    target_header_dir=$with_headers
> > > 
> > > In the common case of just using --with-headers, this now sets
> > > target_header_dir to "yes", which is not particularly useful.
> > 
> > --with-headers without a path to an argument?
> > Odd but that *should* work.  I see old lines here and there
> > including *toplevel* configure.ac that refers to that.
> 
> Yes, pretty much the only use for --with-headers without argument was to
> short-circuit the inhibit_libc test.
> 
> > > Now I understand that you didn't introduce those lines, and they were already
> > > wrong before your patch; but after the patch the problem now actually matters.
> > > Before the patch, I could always use --with-header to say: just assume headers
> > > are present in the prefix, and everything worked.
> > 
> > At a quick glance and my initial guess there's a missing two or
> > four lines checking for with_headers=yes.
> > 
> > > This is not a critical problem since I have a work-around: remove --with-headers
> > > and also manually create a symlink from sys-include to include in the prefix.
> > > But it would still be nice to avoid having to do the symlink ...
> > 
> > I'd recommend writing a patch handling that "yes".
> > I know I'm the one "exposing a latent bug" but you're in a much
> > better position to test it.
> 
> So the question is what this should do then?  Should I simply add back the
> behavior that when using --with-headers, we never get inhibit_libc set?

Well, except for the "never".

> Or should we simply ignore --with-headers and check for the presence of
> headers installed in the prefix?

Um, are those contradicting alternatives?  (Don't make me *think*! :)

Anyway, with_headers=yes/no should simply short-circuit an
inspection of $target_header_dir regarding setting inhibit_libc.
I guess.  But then again, target_header_dir really needs to be
set usefully for inspection, or else every use of it needs to be
dominated by a with_headers=yes test or something.

>  This would work too, once we solve the
> sys-include vs. include problem.

I think *toplevel* configure.ac needs a "yes" check too, that's
all.  (Oh wait, it causes a *copy* to the sys-include target
directory, *outside* of make install and not observing $destdir.
That's a problem by itself.  Though, I guess we shrug and say
"incidental".)

brgds, H-P

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

[Ulrich Weigand]

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 --with-headers, $target_header_dir is something along the
lines of "<prefix>/spu/sys-include", which *does not exist* on my
system.  However, all newlib headers including stdio.h are actually
present, just in "<prefix>/spu/include".

> Maybe make with_headers=yes (i.e. not a path) have the effect of
> setting target_header_dir to include instead of sys-include?

That would solve my problem.  However, if with_headers is not set at all,
shouldn't we then *also* set it to include?

I don't really particularly want to use --with-headers, it's just that
this is what worked in the past.  Ideally, it would be best if everything
just worked as expected without any option if there are indeed already
headers installed in the prefix.

> Anyway, with_headers=yes/no should simply short-circuit an
> inspection of $target_header_dir regarding setting inhibit_libc.
> I guess.  But then again, target_header_dir really needs to be
> set usefully for inspection, or else every use of it needs to be
> dominated by a with_headers=yes test or something.

Well, every other use of $target_header_dir does not in fact matter
on the SPU (because they check for features that aren't present in
newlib and/or on the SPU anyway).  That's why the weird behaviour
did not really matter in the past ...

So short-circuting just for inhibit_libc would get everything back
to where we were before your patch.  But I agree this is not really
the right solution.

My preferred solution would be to set $target_header_dir to include
instead of sys-include, always.  I'm just a bit worried if this may
break other users that have a workflow that somehow works with the
current setup using sys-include.  I guess my underlying problem is
that I don't quite understand how the whole sys-include thing was
intended to work in the first place ... 

[ Note there's also CROSS_SYSTEM_HEADER_DIR, which is also sometimes
set to sys-include ... ]

Bye,
Ulrich

-- 
  Dr. Ulrich Weigand
  GNU/Linux compilers and toolchain
  Ulrich.Weigand@de.ibm.com

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

[Hans-Peter Nilsson]

> From: Ulrich Weigand <uweigand@de.ibm.com>
> 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.

> > 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 one that works?)

> That would solve my problem.  However, if with_headers is not set at all,
> shouldn't we then *also* set it to include?

Definitely not, only one reason of several being as that'd break
current use.

> I don't really particularly want to use --with-headers, it's just that
> this is what worked in the past.  Ideally, it would be best if everything
> just worked as expected without any option if there are indeed already
> headers installed in the prefix.

--enable-dwim? :]

> > Anyway, with_headers=yes/no should simply short-circuit an
> > inspection of $target_header_dir regarding setting inhibit_libc.
> > I guess.  But then again, target_header_dir really needs to be
> > set usefully for inspection, or else every use of it needs to be
> > dominated by a with_headers=yes test or something.
> 
> Well, every other use of $target_header_dir does not in fact matter
> on the SPU (because they check for features that aren't present in
> newlib and/or on the SPU anyway).  That's why the weird behaviour
> did not really matter in the past ...
>
> So short-circuting just for inhibit_libc would get everything back
> to where we were before your patch.  But I agree this is not really
> the right solution.
> 
> My preferred solution would be to set $target_header_dir to include
> instead of sys-include, always.  I'm just a bit worried if this may
> break other users that have a workflow that somehow works with the
> current setup using sys-include.

(T would: proof of existence here.)  I'm more than worried!
Please don't suggest to change a toolchain configuration item
only because you used something that half-way worked, then
broke, like this.  Not the least when also saying the below:

>  I guess my underlying problem is
> that I don't quite understand how the whole sys-include thing was
> intended to work in the first place ... 

I don't know when "include" will work and not, in particular
compared to "sys-include".

> [ Note there's also CROSS_SYSTEM_HEADER_DIR, which is also sometimes
> set to sys-include ... ]

Always, in the absence of sysroot.

brgds, H-P

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

[Ulrich Weigand]

Hans-Peter Nilsson wrote:
> 
> > From: Ulrich Weigand <uweigand@de.ibm.com>
> > 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 one that works?)

So what does "works" mean, here?  Do you expect that all headers are
present either in include or all in sys-include?  Or is there a
scenario where some headers may be in either directory, and you'd
have to check separately for any header you want to access?

> > My preferred solution would be to set $target_header_dir to include
> > instead of sys-include, always.  I'm just a bit worried if this may
> > break other users that have a workflow that somehow works with the
> > current setup using sys-include.
> 
> (T would: proof of existence here.)  I'm more than worried!
> Please don't suggest to change a toolchain configuration item
> only because you used something that half-way worked, then
> broke, like this.  Not the least when also saying the below:
> 
> >  I guess my underlying problem is
> > that I don't quite understand how the whole sys-include thing was
> > intended to work in the first place ... 
> 
> I don't know when "include" will work and not, in particular
> compared to "sys-include".

So I wondering: what is your current setup?  What headers do you have
in sys-include, and how did they get there?  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.
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?

Bye,
Ulrich

-- 
  Dr. Ulrich Weigand
  GNU/Linux compilers and toolchain
  Ulrich.Weigand@de.ibm.com

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

[Hans-Peter Nilsson]

> From: Ulrich Weigand <uweigand@de.ibm.com>
> Date: Wed, 7 Oct 2015 17:32:12 +0200

> Hans-Peter Nilsson wrote:
> > 
> > > From: Ulrich Weigand <uweigand@de.ibm.com>
> > > 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 one that works?)
> 
> So what does "works" mean, here?  Do you expect that all headers are
> present either in include or all in sys-include?  Or is there a
> scenario where some headers may be in either directory, and you'd
> have to check separately for any header you want to access?

*I* don't know.  Perhaps?  I don't have that setup.

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?

> > > My preferred solution would be to set $target_header_dir to include
> > > instead of sys-include, always.  I'm just a bit worried if this may
> > > break other users that have a workflow that somehow works with the
> > > current setup using sys-include.
> > 
> > (T would: proof of existence here.)  I'm more than worried!
> > Please don't suggest to change a toolchain configuration item
> > only because you used something that half-way worked, then
> > broke, like this.  Not the least when also saying the below:
> > 
> > >  I guess my underlying problem is
> > > that I don't quite understand how the whole sys-include thing was
> > > intended to work in the first place ... 
> > 
> > I don't know when "include" will work and not, in particular
> > compared to "sys-include".
> 
> 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>).

>  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.

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...

> 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.

brgds, H-P

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

[Ulrich Weigand]

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.Weigand@de.ibm.com

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

[Hans-Peter Nilsson]

> 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

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

[Ulrich Weigand]

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
> > 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...

So overall, I now this is probably the best way forward:

1) Fix --with-headers to work just like no argument does now,
   i.e. look in sys-include.

This is a simple bugfix that brings behavior in line with
documentation.  It does imply that everybody has to use
sys-include, but that seems to be accepted practice anyway.
(For me, it just means adding a symlink.)

If at some point we do want to make things work without sys-include,
I see two options:

2a) Change <no argument> to not look into sys-include, but include.

This would be a change in existing behavior that would affect some
users.  (They could get the old behavior back by simply adding
--with-headers to their configure line, however.)

--or--

2b) Change target_header_dir from a single directory to a list of
    directories, and check all of these for header files.  This list
    would typically include both sys-include and include.

This should not change behavior for any existing user, and would
bring the header search at configure time in line with the actual
search order used by the compiler at run time, which will probably
be the least surprise to users anyway ...


For 1), something like the following should probably suffice:

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 test x$host != x$target || test "x$TARGET_SYSTEM_ROOT" != x; then
-  if test "x$with_headers" != x; then
+  if test "x$with_headers" != x && test "x$with_headers" != xyes; then
     target_header_dir=$with_headers
   elif test "x$with_sysroot" = x; then
     target_header_dir="${test_exec_prefix}/${target_noncanonical}/sys-include"


I'll probably not spend any more time right now to try to implement
either of the 2) variants; I can live with using sys-include for now.

Bye,
Ulrich

-- 
  Dr. Ulrich Weigand
  GNU/Linux compilers and toolchain
  Ulrich.Weigand@de.ibm.com

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

[Hans-Peter Nilsson]

> From: Ulrich Weigand <uweigand@de.ibm.com>
> 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 files.  This list
>     would typically include both sys-include and include.
> 
> This should not change behavior for any existing user, and would
> bring the header search at configure time in line with the actual
> search order used by the compiler at run time, which will probably
> be the least surprise to users anyway ...

Agreed.  Just pointing out that it would take some effort in
gcc/configure.ac.

> For 1), something like the following should probably suffice:
> 
> 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 test x$host != x$target || test "x$TARGET_SYSTEM_ROOT" != x; then
> -  if test "x$with_headers" != x; then
> +  if test "x$with_headers" != x && test "x$with_headers" != xyes; then
>      target_header_dir=$with_headers
>    elif test "x$with_sysroot" = x; then
>      target_header_dir="${test_exec_prefix}/${target_noncanonical}/sys-include"
> 
> 
> I'll probably not spend any more time right now to try to implement
> either of the 2) variants; I can live with using sys-include for now.

To be clear (to those skipping most of the thread), I'm ok with this.

Thanks.

brgds, H-P

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

[Bernd Schmidt]

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 test x$host != x$target || test "x$TARGET_SYSTEM_ROOT" != x; then
> -  if test "x$with_headers" != x; then
> +  if test "x$with_headers" != x && test "x$with_headers" != xyes; then
>       target_header_dir=$with_headers
>     elif test "x$with_sysroot" = x; then
>       target_header_dir="${test_exec_prefix}/${target_noncanonical}/sys-include"

I'm missing the beginning of this conversation, but this looks like a 
reasonable change (avoiding target_header_dir=yes for --with-headers). 
So, approved.


Bernd

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

[Andre Vieira (lists)]

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 @@ elif test "x$TARGET_SYSTEM_ROOT" != x; t
>>   fi
>>
>>   if test x$host != x$target || test "x$TARGET_SYSTEM_ROOT" != x; then
>> -  if test "x$with_headers" != x; then
>> +  if test "x$with_headers" != x && test "x$with_headers" != xyes; then
>>       target_header_dir=$with_headers
>>     elif test "x$with_sysroot" = x; then
>>      
>> target_header_dir="${test_exec_prefix}/${target_noncanonical}/sys-include"
>>
> 
> I'm missing the beginning of this conversation, but this looks like a
> reasonable change (avoiding target_header_dir=yes for --with-headers).
> So, approved.
> 
> 
> Bernd
> 
Hi there,

I was wondering why this never made it to trunk. I am currently running
into an issue that this patch would fix.

Cheers,
Andre

[arm-embedded]: Don't ignore target_header_dir when deciding inhibit_libc

[Andre Vieira (lists)]

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)
>>> +++ gcc/configure.ac    (working copy)
>>> @@ -1993,7 +1993,7 @@ elif test "x$TARGET_SYSTEM_ROOT" != x; t
>>>   fi
>>>
>>>   if test x$host != x$target || test "x$TARGET_SYSTEM_ROOT" != x; then
>>> -  if test "x$with_headers" != x; then
>>> +  if test "x$with_headers" != x && test "x$with_headers" != xyes; then
>>>       target_header_dir=$with_headers
>>>     elif test "x$with_sysroot" = x; then
>>>      
>>> target_header_dir="${test_exec_prefix}/${target_noncanonical}/sys-include"
>>>
>>
>> I'm missing the beginning of this conversation, but this looks like a
>> reasonable change (avoiding target_header_dir=yes for --with-headers).
>> So, approved.
>>
>>
>> Bernd
>>
> Hi there,
> 
> I was wondering why this never made it to trunk. I am currently running
> into an issue that this patch would fix.
> 
> Cheers,
> Andre
> 
We decided to apply this to the embedded-5-branch at revision r234576.

Cheers,
Andre

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

[Andre Vieira (lists)]

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)
>>> +++ gcc/configure.ac    (working copy)
>>> @@ -1993,7 +1993,7 @@ elif test "x$TARGET_SYSTEM_ROOT" != x; t
>>>   fi
>>>
>>>   if test x$host != x$target || test "x$TARGET_SYSTEM_ROOT" != x; then
>>> -  if test "x$with_headers" != x; then
>>> +  if test "x$with_headers" != x && test "x$with_headers" != xyes; then
>>>       target_header_dir=$with_headers
>>>     elif test "x$with_sysroot" = x; then
>>>      
>>> target_header_dir="${test_exec_prefix}/${target_noncanonical}/sys-include"
>>>
>>
>> I'm missing the beginning of this conversation, but this looks like a
>> reasonable change (avoiding target_header_dir=yes for --with-headers).
>> So, approved.
>>
>>
>> Bernd
>>
> Hi there,
> 
> I was wondering why this never made it to trunk. I am currently running
> into an issue that this patch would fix.
> 
> Cheers,
> Andre
> 
Ping.

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

[Andre Vieira (lists)]

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
>>>> ===================================================================
>>>> --- gcc/configure.ac    (revision 228530)
>>>> +++ gcc/configure.ac    (working copy)
>>>> @@ -1993,7 +1993,7 @@ elif test "x$TARGET_SYSTEM_ROOT" != x; t
>>>>   fi
>>>>
>>>>   if test x$host != x$target || test "x$TARGET_SYSTEM_ROOT" != x; then
>>>> -  if test "x$with_headers" != x; then
>>>> +  if test "x$with_headers" != x && test "x$with_headers" != xyes; then
>>>>       target_header_dir=$with_headers
>>>>     elif test "x$with_sysroot" = x; then
>>>>      
>>>> target_header_dir="${test_exec_prefix}/${target_noncanonical}/sys-include"
>>>>
>>>
>>> I'm missing the beginning of this conversation, but this looks like a
>>> reasonable change (avoiding target_header_dir=yes for --with-headers).
>>> So, approved.
>>>
>>>
>>> Bernd
>>>
>> Hi there,
>>
>> I was wondering why this never made it to trunk. I am currently running
>> into an issue that this patch would fix.
>>
>> Cheers,
>> Andre
>>
> Ping.
> 
Ping.

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

[Ulrich Weigand]

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
> >>>> ===================================================================
> >>>> --- gcc/configure.ac    (revision 228530)
> >>>> +++ gcc/configure.ac    (working copy)
> >>>> @@ -1993,7 +1993,7 @@ elif test "x$TARGET_SYSTEM_ROOT" != x; t
> >>>>   fi
> >>>>
> >>>>   if test x$host != x$target || test "x$TARGET_SYSTEM_ROOT" != x; then
> >>>> -  if test "x$with_headers" != x; then
> >>>> +  if test "x$with_headers" != x && test "x$with_headers" != xyes; then
> >>>>       target_header_dir=$with_headers
> >>>>     elif test "x$with_sysroot" = x; then
> >>>>      
> >>>> target_header_dir="${test_exec_prefix}/${target_noncanonical}/sys-include"
> >>>>
> >>>
> >>> I'm missing the beginning of this conversation, but this looks like a
> >>> reasonable change (avoiding target_header_dir=yes for --with-headers).
> >>> So, approved.
> >>>
> >>>
> >>> Bernd
> >>>
> >> Hi there,
> >>
> >> I was wondering why this never made it to trunk. I am currently running
> >> into an issue that this patch would fix.

Seems I never actually checked this in, even though it was approved.
Thanks for the reminder, I've now checked the patch in.

Bye,
Ulrich

-- 
  Dr. Ulrich Weigand
  GNU/Linux compilers and toolchain
  Ulrich.Weigand@de.ibm.com

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

[Andre Vieira (lists)]

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: 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 test x$host != x$target || test "x$TARGET_SYSTEM_ROOT" != x; then
>>>>>> -  if test "x$with_headers" != x; then
>>>>>> +  if test "x$with_headers" != x && test "x$with_headers" != xyes; then
>>>>>>       target_header_dir=$with_headers
>>>>>>     elif test "x$with_sysroot" = x; then
>>>>>>      
>>>>>> target_header_dir="${test_exec_prefix}/${target_noncanonical}/sys-include"
>>>>>>
>>>>>
>>>>> I'm missing the beginning of this conversation, but this looks like a
>>>>> reasonable change (avoiding target_header_dir=yes for --with-headers).
>>>>> So, approved.
>>>>>
>>>>>
>>>>> Bernd
>>>>>
>>>> Hi there,
>>>>
>>>> I was wondering why this never made it to trunk. I am currently running
>>>> into an issue that this patch would fix.
> 
> Seems I never actually checked this in, even though it was approved.
> Thanks for the reminder, I've now checked the patch in.
> 
> Bye,
> Ulrich
> 

Is it OK to backport this fix to GCC-6? It applies cleanly, builds and
no regressions for arm-none-eabi.

Regards,
Andre

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

[Andre Vieira (lists)]

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 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 test x$host != x$target || test "x$TARGET_SYSTEM_ROOT" != x; then
>>>>>>> -  if test "x$with_headers" != x; then
>>>>>>> +  if test "x$with_headers" != x && test "x$with_headers" != xyes; then
>>>>>>>       target_header_dir=$with_headers
>>>>>>>     elif test "x$with_sysroot" = x; then
>>>>>>>      
>>>>>>> target_header_dir="${test_exec_prefix}/${target_noncanonical}/sys-include"
>>>>>>>
>>>>>>
>>>>>> I'm missing the beginning of this conversation, but this looks like a
>>>>>> reasonable change (avoiding target_header_dir=yes for --with-headers).
>>>>>> So, approved.
>>>>>>
>>>>>>
>>>>>> Bernd
>>>>>>
>>>>> Hi there,
>>>>>
>>>>> I was wondering why this never made it to trunk. I am currently running
>>>>> into an issue that this patch would fix.
>>
>> Seems I never actually checked this in, even though it was approved.
>> Thanks for the reminder, I've now checked the patch in.
>>
>> Bye,
>> Ulrich
>>
> 
> Is it OK to backport this fix to GCC-6? It applies cleanly, builds and
> no regressions for arm-none-eabi.
> 
> Regards,
> Andre
> 
Ping.