Use a non-empty test program to test ability to link

This patch is for PR 79193 and 88999, problems where libstdc++ is 
mis-configuring itself when building for a bare-metal target because it 
thinks it can link programs without pulling in the BSP that provides 
low-level I/O support.  (Specifically, this was observed on nios2-elf 
with Newlib and GDB semihosting.)  It'll build just fine if it 
recognizes that it can only compile programs and not link them, but it's 
confused because using an empty program to test for ability to link 
succeeds.

Is this configure change OK, and suitable for stage 4?

BTW, I did run autoconf in every subdirectory that contains a 
configure.ac, but it appears only libstc++-v3 actually uses this test; 
all the other regenerated configure scripts were unchanged.

-Sandra

On 05/02/20 11:52 -0700, Sandra Loosemore wrote:
>This patch is for PR 79193 and 88999, problems where libstdc++ is 
>mis-configuring itself when building for a bare-metal target because 
>it thinks it can link programs without pulling in the BSP that 
>provides low-level I/O support.  (Specifically, this was observed on 
>nios2-elf with Newlib and GDB semihosting.)  It'll build just fine if 
>it recognizes that it can only compile programs and not link them, but 
>it's confused because using an empty program to test for ability to 
>link succeeds.
>
>Is this configure change OK, and suitable for stage 4?
>
>BTW, I did run autoconf in every subdirectory that contains a 
>configure.ac, but it appears only libstc++-v3 actually uses this test; 
>all the other regenerated configure scripts were unchanged.

Thanks for making this work properly.

No objection from me, but I can't approve the top-level configury
change, and the whole "no executables" thing is a bit of a mystery to
me.  Joseph is probably the right person to approve that, if no other
relevant maintainer responds.

Sandra Loosemore <sandra@codesourcery.com> writes:
> This patch is for PR 79193 and 88999, problems where libstdc++ is 
> mis-configuring itself when building for a bare-metal target because it 
> thinks it can link programs without pulling in the BSP that provides 
> low-level I/O support.  (Specifically, this was observed on nios2-elf 
> with Newlib and GDB semihosting.)  It'll build just fine if it 
> recognizes that it can only compile programs and not link them, but it's 
> confused because using an empty program to test for ability to link 
> succeeds.
>
> Is this configure change OK, and suitable for stage 4?
>
> BTW, I did run autoconf in every subdirectory that contains a 
> configure.ac, but it appears only libstc++-v3 actually uses this test; 
> all the other regenerated configure scripts were unchanged.

LGTM FWIW.  AIUI the effect will be to use the hard-coded list of
supported newlib features (as intended) instead of trying to detech them
at configure time.  But I guess there's a risk that this could unmask
latent problems on other targets by enabling features that some BSPs don't
support, either due to a limited libgloss or due to some other restriction.
Jeff's autotesters will probably pick that up though.

Thanks,
Richard

>
> -Sandra
>
> From 44b769a9b5e01a58c9b89b24ca5a00fc1ff53012 Mon Sep 17 00:00:00 2001
> From: Sandra Loosemore <sandra@codesourcery.com>
> Date: Wed, 5 Feb 2020 10:03:58 -0800
> Subject: [PATCH] Use a non-empty test program to test ability to link.
>
> On bare-metal targets, I/O support is typically provided by a BSP and
> requires a linker script and/or hosting library to be specified on the
> linker command line.  Linking an empty program with the default linker
> script may succeed, however, which confuses libstdc++ configuration
> when programs that probe for the presence of various I/O features fail
> with link errors.
>
> 2020-02-05  Sandra Loosemore  <sandra@codesourcery.com>
>
> 	PR libstdc++/79193
> 	PR libstdc++/88999
>
> 	config/
> 	* no-executables.m4: Use a non-empty program to test for linker
> 	support.
>
> 	libstdc++v-3/
> 	* configure: Regenerated.
> ---
>  config/ChangeLog         | 8 ++++++++
>  config/no-executables.m4 | 4 +++-
>  libstdc++-v3/ChangeLog   | 7 +++++++
>  libstdc++-v3/configure   | 4 ++--
>  4 files changed, 20 insertions(+), 3 deletions(-)
>
> diff --git a/config/ChangeLog b/config/ChangeLog
> index f1fec81..d2a12bd 100644
> --- a/config/ChangeLog
> +++ b/config/ChangeLog
> @@ -1,3 +1,11 @@
> +2020-02-05  Sandra Loosemore  <sandra@codesourcery.com>
> +
> +	PR libstdc++/79193
> +	PR libstdc++/88999
> +
> +	* no-executables.m4: Use a non-empty program to test for linker
> +	support.
> +
>  2020-02-01  Andrew Burgess  <andrew.burgess@embecosm.com>
>  
>  	* lib-link.m4 (AC_LIB_LINKFLAGS_BODY): Update shell syntax.
> diff --git a/config/no-executables.m4 b/config/no-executables.m4
> index 9061624..6842f84 100644
> --- a/config/no-executables.m4
> +++ b/config/no-executables.m4
> @@ -25,7 +25,9 @@ AC_BEFORE([$0], [_AC_COMPILER_EXEEXT])
>  AC_BEFORE([$0], [AC_LINK_IFELSE])
>  
>  m4_define([_AC_COMPILER_EXEEXT],
> -[AC_LANG_CONFTEST([AC_LANG_PROGRAM()])
> +[AC_LANG_CONFTEST([AC_LANG_PROGRAM(
> +		     [#include <stdio.h>],
> +		     [printf ("hello world\n");])])
>  # FIXME: Cleanup?
>  AS_IF([AC_TRY_EVAL(ac_link)], [gcc_no_link=no], [gcc_no_link=yes])
>  if test x$gcc_no_link = xyes; then
> diff --git a/libstdc++-v3/ChangeLog b/libstdc++-v3/ChangeLog
> index 76a6e2b..46ab7c0 100644
> --- a/libstdc++-v3/ChangeLog
> +++ b/libstdc++-v3/ChangeLog
> @@ -1,3 +1,10 @@
> +2020-02-05  Sandra Loosemore  <sandra@codesourcery.com>
> +
> +	PR libstdc++/79193
> +	PR libstdc++/88999
> +
> +	* configure: Regenerated.
> +
>  2020-02-05  Jonathan Wakely  <jwakely@redhat.com>
>  
>  	* include/bits/iterator_concepts.h (iter_reference_t)
> diff --git a/libstdc++-v3/configure b/libstdc++-v3/configure
> index a39c33b..9f9c5a2 100755
> --- a/libstdc++-v3/configure
> +++ b/libstdc++-v3/configure
> @@ -4130,11 +4130,11 @@ done
>  
>  cat confdefs.h - <<_ACEOF >conftest.$ac_ext
>  /* end confdefs.h.  */
> -
> +#include <stdio.h>
>  int
>  main ()
>  {
> -
> +printf ("hello world\n");
>    ;
>    return 0;
>  }

On Wed, 5 Feb 2020, Sandra Loosemore wrote:

> This patch is for PR 79193 and 88999, problems where libstdc++ is
> mis-configuring itself when building for a bare-metal target because it thinks
> it can link programs without pulling in the BSP that provides low-level I/O
> support.  (Specifically, this was observed on nios2-elf with Newlib and GDB
> semihosting.)  It'll build just fine if it recognizes that it can only compile
> programs and not link them, but it's confused because using an empty program
> to test for ability to link succeeds.
> 
> Is this configure change OK, and suitable for stage 4?
> 
> BTW, I did run autoconf in every subdirectory that contains a configure.ac,
> but it appears only libstc++-v3 actually uses this test; all the other
> regenerated configure scripts were unchanged.

There's some problem with that regeneration, then; every directory where 
configure.ac mentions GCC_NO_EXECUTABLES should have a resulting change (I 
tested regenerating in libgcc/ with this patch applied and got such a 
change, for example).

On 2/7/20 3:24 PM, Joseph Myers wrote:
> On Wed, 5 Feb 2020, Sandra Loosemore wrote:
> 
>> This patch is for PR 79193 and 88999, problems where libstdc++ is
>> mis-configuring itself when building for a bare-metal target because it thinks
>> it can link programs without pulling in the BSP that provides low-level I/O
>> support.  (Specifically, this was observed on nios2-elf with Newlib and GDB
>> semihosting.)  It'll build just fine if it recognizes that it can only compile
>> programs and not link them, but it's confused because using an empty program
>> to test for ability to link succeeds.
>>
>> Is this configure change OK, and suitable for stage 4?
>>
>> BTW, I did run autoconf in every subdirectory that contains a configure.ac,
>> but it appears only libstc++-v3 actually uses this test; all the other
>> regenerated configure scripts were unchanged.
> 
> There's some problem with that regeneration, then; every directory where
> configure.ac mentions GCC_NO_EXECUTABLES should have a resulting change (I
> tested regenerating in libgcc/ with this patch applied and got such a
> change, for example).

Hmmm.  I just tried that again and got nothing.  Do I have to do 
something other than just run "autoconf" in that directory?  I'm always 
confused by anything involving configuration changes.  :-(

-Sandra

On Sat, 8 Feb 2020, Sandra Loosemore wrote:

> > > BTW, I did run autoconf in every subdirectory that contains a
> > > configure.ac,
> > > but it appears only libstc++-v3 actually uses this test; all the other
> > > regenerated configure scripts were unchanged.
> > 
> > There's some problem with that regeneration, then; every directory where
> > configure.ac mentions GCC_NO_EXECUTABLES should have a resulting change (I
> > tested regenerating in libgcc/ with this patch applied and got such a
> > change, for example).
> 
> Hmmm.  I just tried that again and got nothing.  Do I have to do something
> other than just run "autoconf" in that directory?  I'm always confused by
> anything involving configuration changes.  :-(

Just running autoconf in that directory should suffice to get configure 
regenerated with the change.

On 2/10/20 3:58 PM, Joseph Myers wrote:
> On Sat, 8 Feb 2020, Sandra Loosemore wrote:
> 
>>>> BTW, I did run autoconf in every subdirectory that contains a
>>>> configure.ac,
>>>> but it appears only libstc++-v3 actually uses this test; all the other
>>>> regenerated configure scripts were unchanged.
>>>
>>> There's some problem with that regeneration, then; every directory where
>>> configure.ac mentions GCC_NO_EXECUTABLES should have a resulting change (I
>>> tested regenerating in libgcc/ with this patch applied and got such a
>>> change, for example).
>>
>> Hmmm.  I just tried that again and got nothing.  Do I have to do something
>> other than just run "autoconf" in that directory?  I'm always confused by
>> anything involving configuration changes.  :-(
> 
> Just running autoconf in that directory should suffice to get configure
> regenerated with the change.

Hmmm, I tried again and saw that autoconf didn't even touch the 
timestamp on the existing configure file, but I was able to force it to 
regenerate the files by removing the old ones first.  Is this version of 
the patch OK to check in?

-Sandra

On Wed, 12 Feb 2020, Sandra Loosemore wrote:

> Hmmm, I tried again and saw that autoconf didn't even touch the timestamp on
> the existing configure file, but I was able to force it to regenerate the
> files by removing the old ones first.  Is this version of the patch OK to
> check in?

OK.