Does the buildtime HAVE_GETRANDOM_SYSCALL check actually make sense?
I think I've found a better explanation than mere timing or coincidence for why we haven't had any problem reports regarding Python 3.5.1 blocking in Fedora or in the Software Collections builds for RHEL and CentOS: those builds currently aren't even trying to use the new syscall, and are instead always using the older non-blocking /dev/urandom behaviour. My assumption in https://bugzilla.redhat.com/show_bug.cgi?id=1350123 is that this is due to those binaries being built against a version of the kernel that doesn't have that syscall defined, which means the config script doesn't define HAVE_GETRANDOM_SYSCALL, which means we compile out the code that tries calling it at runtime. Does skipping trying the new syscall at runtime just because the build server is running an older kernel actually make sense? Or we would be better off defining a different TRY_GETRANDOM_SYSCALL that looks for some other indicator that this is a build for a platform where getrandom() might be available at runtime, even if it's not available at build time. Cheers, Nick. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia
The configure check ensures that constants required to build random.c are available. We can only run this check at the compilation. I don't want to maintain hardcoded constants. The proper fix is to add getrandom() to the libc: https://sourceware.org/bugzilla/show_bug.cgi?id=17252 But you may have the same issue if you build the lib with "old" header files. Victor
On 26 June 2016 at 02:30, Victor Stinner <victor.stinner@gmail.com> wrote:
The configure check ensures that constants required to build random.c are available. We can only run this check at the compilation. I don't want to maintain hardcoded constants.
The proper fix is to add getrandom() to the libc: https://sourceware.org/bugzilla/show_bug.cgi?id=17252
But you may have the same issue if you build the lib with "old" header files.
mock (the Fedora build utility, not the Python testing utility) will use the updated header files when building against the newer glibc, so not worrying about this until it's resolved there sounds fine to me. Cheers, Nick. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia
On 2 July 2016 at 23:30, Nick Coghlan <ncoghlan@gmail.com> wrote:
On 26 June 2016 at 02:30, Victor Stinner <victor.stinner@gmail.com> wrote:
The configure check ensures that constants required to build random.c are available. We can only run this check at the compilation. I don't want to maintain hardcoded constants.
The proper fix is to add getrandom() to the libc: https://sourceware.org/bugzilla/show_bug.cgi?id=17252
But you may have the same issue if you build the lib with "old" header files.
mock (the Fedora build utility, not the Python testing utility) will use the updated header files when building against the newer glibc, so not worrying about this until it's resolved there sounds fine to me.
Huh, I should have caught up on the issue I filed against Fedora first - it appears there's something going wrong with the config scripts, since the syscall *is* available and working on the build servers. Either way, nothing for upstream to worry about until we figure out why the config script is giving the wrong answer (since my original theory of not having access to the syscall turned out to be wrong). Cheers, Nick. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia
participants (2)
-
Nick Coghlan -
Victor Stinner