[Bug libstdc++/79193] New: libstdc++ configure incorrectly decides linking works for cross-compiler

["sandra at gcc dot gnu.org" <gcc-bugzilla at gcc dot gnu dot org>]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79193

            Bug ID: 79193
           Summary: libstdc++ configure incorrectly decides linking works
                    for cross-compiler
           Product: gcc
           Version: 7.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: libstdc++
          Assignee: unassigned at gcc dot gnu.org
          Reporter: sandra at gcc dot gnu.org
  Target Milestone: ---

I've discovered that libstdc++ is being misconfigured for a bare-metal target
that uses newlib. For our toolchains we separately provide board-specific
linker scripts and a library that includes startup code and low-level I/O
support (either GDB semihosting, hooks to Uboot/Yamon/etc, or dummy entry
points for unhosted applications).

Fairly early on, the libstdc++-v3 configure script tries to determine whether
it can link executables by trying to build this test program:

int
main ()
{

;
return 0;
}

It turns out that this program actually is simple enough to link with only a
warning (not an error) about _start being undefined when the linker is invoked
without specifying without a linker script, startup code, or hosting library.
Based on that, the configure script sets gcc_no_link=no and then fails to set
cross_compiling=yes.

I noticed this while tracking down a bug that turned out to be due to this
subsequent check for C99 stdio.h support returning the wrong result:

#include <stdio.h>
#include <stdarg.h>
void foo(char* fmt, ...)
{
va_list args; va_start(args, fmt);
vfscanf(stderr, "%i", args);
vscanf("%i", args);
vsnprintf(fmt, 0, "%i", args);
vsscanf(fmt, "%i", args);
snprintf(fmt, 0, "%i");
}
int
main ()
{

;
return 0;
}

The link command is failing with undefined symbol errors; the C99 functions
it's checking for are present and provided by newlib, but they suck in
low-level primitives that would be provided by the missing BSP hosting library,
so configure is incorrectly deciding that the C99 I/O support isn't present.

For now I am forcing the initial "can we link?" test to fail by adding
"-Wl,--require-defined=_start" to LDFLAGS_FOR_TARGET, which forces the
subsequent check for C99 I/O functions to compile only instead of compile and
link.  But this is pretty obscure.  Is it possible to fix the configure script
instead?  E.g., to have an explicit option to say "don't try to link for this
target", or to make these checks for C99 features always compile-only instead
of link tests?  Or to use a non-empty program to check whether linking works at
all?