When building native compiler for MinGW/MinGW-w64 'configure' checks for /dev/random simply by if test -r /dev/random && test -r /dev/urandom; then glibcxx_cv_random_tr1=yes; else glibcxx_cv_random_tr1=no; fi Result of this test is incorrect at least for MinGW. MinGW shell is executed in MSYS subsystem, so those devices is available for shell, but MinGW compiled programs will have no access to /dev/random. For some other platforms situation can be the same (/dev/random available for shell, but not for compiled program). I suggest to do a real compile-link-execute test instead of weak shell emulation.
We had an AC_TRY_RUN test, but such kind of test give a lot of problems and we removed it. We had: AC_TRY_RUN([#include <stdio.h> int main() { return !(fopen("/dev/random", "r") && fopen("/dev/urandom", "r")); } ], [ac_random_tr1=yes], [ac_random_tr1=no], [ac_random_tr1=no]) ]) Kai, can you suggest something working on MinGW and not using an AC_TRY_RUN? Or you can just special case MinGW. I have no way of testing such fixes, sorry.
Better to open random devices with "rb"? Or just 'stat' device?
(In reply to comment #1) > We had an AC_TRY_RUN test, but such kind of test give a lot of problems and we > removed it. We had: > > AC_TRY_RUN([#include <stdio.h> > int main() > { > return !(fopen("/dev/random", "r") > && fopen("/dev/urandom", "r")); > } > ], > [ac_random_tr1=yes], [ac_random_tr1=no], > [ac_random_tr1=no]) > ]) > > Kai, can you suggest something working on MinGW and not using an AC_TRY_RUN? Or > you can just special case MinGW. I have no way of testing such fixes, sorry. Well, AC_TRY_RUN is for sure the wrong approach here. As such tests are failing badly on cross-compilers. I think sanest way to solve this is by special-casing mingw targets.
I agree. Care to send a patch for that?
(In reply to comment #3) > Well, AC_TRY_RUN is for sure the wrong approach here. As such tests are > failing badly on cross-compilers. > I think sanest way to solve this is by special-casing mingw targets. This test is already skipped for cross-compilers and done only for native compilers. So AC_TRY_RUN is the only solution, that can check compiler's capabilities (and not the shell's).
(In reply to comment #4) > I agree. Care to send a patch for that? Well, something like this should fix the issue: Index: acinclude.m4 =================================================================== --- acinclude.m4 (Revision 196329) +++ acinclude.m4 (Arbeitskopie) @@ -1739,7 +1739,10 @@ AC_DEFUN([GLIBCXX_CHECK_RANDOM_TR1], [ AC_MSG_CHECKING([for "/dev/random" and "/dev/urandom" for TR1 random_device]) AC_CACHE_VAL(glibcxx_cv_random_tr1, [ if test -r /dev/random && test -r /dev/urandom; then - glibcxx_cv_random_tr1=yes; + case ${target_os} in + *mingw*) glibcxx_cv_random_tr1=no ;; + *) glibcxx_cv_random_tr1=yes ;; + esac else glibcxx_cv_random_tr1=no; fi
Good. I would say, please add a one line comment mentioning the MSYS subsystem issue, etc, test and commit at your ease. Thanks!
Author: ktietz Date: Fri Mar 1 10:23:21 2013 New Revision: 196371 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=196371 Log: PR libstdc++/56475 * acinclude.m4 (GLIBCXX_CHECK_RANDOM_TR1): Disable check for mingw-targets. * configure: Regenerated. Modified: trunk/libstdc++-v3/acinclude.m4 trunk/libstdc++-v3/configure
Fixed on trunk.
Could you fix 4.7 branch too?