[Bug libstdc++/103166] New: [12 regression] wrong dependency on getentropy on newlib-based targets

[Bug libstdc++/103166] New: [12 regression] wrong dependency on getentropy on newlib-based targets

[clyon at gcc dot gnu.org]

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

            Bug ID: 103166
           Summary: [12 regression] wrong dependency on getentropy on
                    newlib-based targets
           Product: gcc
           Version: 12.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: libstdc++
          Assignee: unassigned at gcc dot gnu.org
          Reporter: clyon at gcc dot gnu.org
  Target Milestone: ---

Since r12-5066, I've noticed numerous link failures on aarch64-none-elf like:

FAIL: g++.dg/concepts/expression.C  -std=gnu++17 (test for excess errors)
Excess errors:
/libstdc++-v3/src/c++11/random.cc:179: undefined reference to `getentropy'
/libstdc++-v3/src/c++11/random.cc:179:(.text._ZNSt12_GLOBAL__N_117__libc_getentropyEPv+0x10):
relocation truncated to fit: R_AARCH64_CALL26 against undefined symbol
`getentropy'
/libstdc++-v3/src/c++11/random.cc:452: undefined reference to `getentropy'
/libstdc++-v3/src/c++11/random.cc:452:(.text._ZNSt13random_device7_M_initERKNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEE+0x68):
relocation truncated to fit: R_AARCH64_CALL26 against undefined symbol
`getentropy'
/aci-gcc-fsf/sources/newlib/newlib/libc/stdlib/arc4random.c:89: undefined
reference to `getentropy'
/aci-gcc-fsf/sources/newlib/newlib/libc/stdlib/arc4random.c:89:(.text+0x558):
relocation truncated to fit: R_AARCH64_CALL26 against undefined symbol
`getentropy'

Maybe there's something wrong with the detection of HAVE_GETENTROPY in
configure?

[Bug libstdc++/103166] [12 regression] wrong dependency on getentropy on newlib-based targets

[pinskia at gcc dot gnu.org]

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

Andrew Pinski <pinskia at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Last reconfirmed|                            |2021-11-10
             Status|UNCONFIRMED                 |NEW
     Ever confirmed|0                           |1

--- Comment #1 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
Note the revision is r12-5056.

So there are two issues here both dealing with getentropy; one is a newlib
issue and the other is a libstdc++ issue (well maybe still a newlib one).

Newlib issue:
Newlib includes a version of arc4random which requires getentropy.

libstdc++/Newlib issue:
libstdc++ detects getentropy in the header and thinks it can work.  newlib
defines it unconditionally too.

Maybe the better fix is to fix newlib?

[Bug libstdc++/103166] [12 regression] wrong dependency on getentropy on newlib-based targets

[redi at gcc dot gnu.org]

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

Jonathan Wakely <redi at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |ASSIGNED
           Assignee|unassigned at gcc dot gnu.org      |redi at gcc dot gnu.org
      Known to work|                            |11.2.1
      Known to fail|                            |12.0
           Priority|P3                          |P1
           Keywords|                            |link-failure
   Target Milestone|---                         |12.0

--- Comment #2 from Jonathan Wakely <redi at gcc dot gnu.org> ---
(In reply to Christophe Lyon from comment #0)
> Maybe there's something wrong with the detection of HAVE_GETENTROPY in
> configure?

We only do a compile test, not link, so if newlib declares it in <unistd.h> but
doesn't define it, we detect it incorrectly. But we avoid link tests in
configure, because there are problems for cross-compilers.

[Bug libstdc++/103166] [12 regression] wrong dependency on getentropy on newlib-based targets

[sandra at gcc dot gnu.org]

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

sandra at gcc dot gnu.org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |sandra at gcc dot gnu.org

--- Comment #3 from sandra at gcc dot gnu.org ---
I'm seeing these failures in my nios2-elf test results today too.  :-(

[Bug libstdc++/103166] [12 regression] wrong dependency on getentropy on newlib-based targets

[hp at gcc dot gnu.org]

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

Hans-Peter Nilsson <hp at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |hp at gcc dot gnu.org

--- Comment #4 from Hans-Peter Nilsson <hp at gcc dot gnu.org> ---
I have a patch using GCC_TRY_COMPILE_OR_LINK instead of AC_TRY_COMPILE for
those function, since I foolishly went about to fix this before looking in
bugzilla. :)

Will post once it's successfully past the first point of failure, sparing
others the churn of finding autoconf-2.69 and automake-2.15.1.  Unless a patch
is already posted?

[Bug libstdc++/103166] [12 regression] wrong dependency on getentropy on newlib-based targets

[redi at gcc dot gnu.org]

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

--- Comment #5 from Jonathan Wakely <redi at gcc dot gnu.org> ---
There's no other patch as far as I know, so that would be great, thanks.

[Bug libstdc++/103166] [12 regression] wrong dependency on getentropy on newlib-based targets

[hp at gcc dot gnu.org]

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

Hans-Peter Nilsson <hp at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                URL|                            |https://gcc.gnu.org/piperma
                   |                            |il/gcc-patches/2021-Novembe
                   |                            |r/584316.html
           Assignee|redi at gcc dot gnu.org            |hp at gcc dot gnu.org

--- Comment #6 from Hans-Peter Nilsson <hp at gcc dot gnu.org> ---
Yoink!

[Bug libstdc++/103166] [12 regression] wrong dependency on getentropy on newlib-based targets

[cvs-commit at gcc dot gnu.org]

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

--- Comment #7 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Hans-Peter Nilsson <hp@gcc.gnu.org>:

https://gcc.gnu.org/g:60f761c7e54f96a287c73a71d0b09ee2b2f8426d

commit r12-5220-g60f761c7e54f96a287c73a71d0b09ee2b2f8426d
Author: Hans-Peter Nilsson <hp@axis.com>
Date:   Fri Nov 12 18:04:43 2021 +0100

    libstdc++: Use GCC_TRY_COMPILE_OR_LINK for getentropy, arc4random

    Since r12-5056-g3439657b0286, there has been a regression in
    test results; an additional 100 FAILs running the g++ and
    libstdc++ testsuite on cris-elf, a newlib target.  The
    failures are linker errors, not finding a definition for
    getentropy.  It appears newlib has since 2017-12-03
    declarations of getentropy and arc4random, and provides an
    implementation of arc4random using getentropy, but provides no
    definition of getentropy, not even a stub yielding ENOSYS.
    This is similar to what it does for many other functions too.

    While fixing newlib (like adding said stub) would likely help,
    it still leaves older newlib releases hanging.  Thankfully,
    the libstdc++ configury test can be improved to try linking
    where possible; using the bespoke GCC_TRY_COMPILE_OR_LINK
    instead of AC_TRY_COMPILE.  BTW, I see a lack of consistency;
    some tests use AC_TRY_COMPILE and some GCC_TRY_COMPILE_OR_LINK
    for no apparent reason, but this commit just amends
    r12-5056-g3439657b0286.

    libstdc++-v3:
            PR libstdc++/103166
            * acinclude.m4 (GLIBCXX_CHECK_GETENTROPY,
GLIBCXX_CHECK_ARC4RANDOM):
            Use GCC_TRY_COMPILE_OR_LINK instead of AC_TRY_COMPILE.
            * configure: Regenerate.

[Bug libstdc++/103166] [12 regression] wrong dependency on getentropy on newlib-based targets

[hp at gcc dot gnu.org]

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

Hans-Peter Nilsson <hp at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|ASSIGNED                    |RESOLVED
         Resolution|---                         |FIXED

--- Comment #8 from Hans-Peter Nilsson <hp at gcc dot gnu.org> ---
Calling it fixed, as observed for cris-elf applying the same patch at
r12-5056-g3439657b0286.

[Bug libstdc++/103166] [12 regression] wrong dependency on getentropy on newlib-based targets

[hp at gcc dot gnu.org]

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

--- Comment #9 from Hans-Peter Nilsson <hp at gcc dot gnu.org> ---
Elaboration: there may be (newlib) targets (build/test setups) where the
test-setup can't link and thus erroneously gets a "yes" for these functions. 
If that happens for you, look into fixing newlib (like, providing a stub that
returns -1 and sets errno=ENOSYS, which would work for libstdc++ as it has a
fallback option - actually several fallback options).

(Or, make newlib stop declaring functions it doesn't completely provide.)

That was my plan B, thankfully GCC_TRY_COMPILE_OR_LINK did the right thing for
my setup. :)

[Bug libstdc++/103166] [12 regression] wrong dependency on getentropy on newlib-based targets

[clyon at gcc dot gnu.org]

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

--- Comment #10 from Christophe Lyon <clyon at gcc dot gnu.org> ---
(In reply to Jonathan Wakely from comment #2)
> (In reply to Christophe Lyon from comment #0)
> > Maybe there's something wrong with the detection of HAVE_GETENTROPY in
> > configure?
> 
> We only do a compile test, not link, so if newlib declares it in <unistd.h>
> but doesn't define it, we detect it incorrectly. But we avoid link tests in
> configure, because there are problems for cross-compilers.

Why do we avoid link tests? Is that because of something like
https://lists.gnu.org/archive/html/autoconf/2007-03/msg00085.html ?

Also I am not sure to understand how this patch fixed the problem?

Before and after this patch we are happy if compilation succeeds, right?

What does the "OR_LINK" part gives us?

[Bug libstdc++/103166] [12 regression] wrong dependency on getentropy on newlib-based targets

[redi at gcc dot gnu.org]

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

--- Comment #11 from Jonathan Wakely <redi at gcc dot gnu.org> ---
(In reply to Christophe Lyon from comment #10)
> Why do we avoid link tests? Is that because of something like
> https://lists.gnu.org/archive/html/autoconf/2007-03/msg00085.html ?

No, I don't think it's related to that, but every time somebody explains it to
me I instantly forget the answer.

Here's what Joseph explained last time I asked:

On some bare-metal targets, the compiler can't link unless you explicitly pass
-T or similar options to select a particular BSP.
For any hosted system supporting shared libraries, at least, the cross
configuration ought to be the same as the native configuration (running the
same configure tests), and hardcoding in crossconfig.m4 tends to be a source of
bugs.