[Bug libstdc++/103166] [12 regression] wrong dependency on getentropy on newlib-based targets
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103166 --- Comment #11 from Jonathan Wakely --- (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.
[Bug libstdc++/103166] [12 regression] wrong dependency on getentropy on newlib-based targets
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103166 --- Comment #10 from Christophe Lyon --- (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 > 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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103166 --- Comment #9 from Hans-Peter Nilsson --- 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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103166 Hans-Peter Nilsson changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #8 from Hans-Peter Nilsson --- 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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103166 --- Comment #7 from CVS Commits --- The master branch has been updated by Hans-Peter Nilsson : https://gcc.gnu.org/g:60f761c7e54f96a287c73a71d0b09ee2b2f8426d commit r12-5220-g60f761c7e54f96a287c73a71d0b09ee2b2f8426d Author: Hans-Peter Nilsson 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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103166 Hans-Peter Nilsson 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 --- Yoink!
[Bug libstdc++/103166] [12 regression] wrong dependency on getentropy on newlib-based targets
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103166 --- Comment #5 from Jonathan Wakely --- 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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103166 Hans-Peter Nilsson changed: What|Removed |Added CC||hp at gcc dot gnu.org --- Comment #4 from Hans-Peter Nilsson --- 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
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103166 Jonathan Wakely 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 --- (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 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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103166 Andrew Pinski changed: What|Removed |Added Last reconfirmed||2021-11-10 Status|UNCONFIRMED |NEW Ever confirmed|0 |1 --- Comment #1 from Andrew Pinski --- 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?
