cpython ./configure's -pthread detection is misbehaving on some variants #599
Comments
|
Oh, I think what's going on is that these are the runs where we're cross-compiling (in the sense of "telling autoconf that we are cross-compiling"), and This particular configure check does if test $ac_cv_kthread = no -a $ac_cv_pthread_is_default = no
then
# -pthread, if available, provides the right #defines
# and linker options to make pthread_create available
# Some compilers won't report that they do not support -pthread,
# so we need to run a program to see whether it really made the
# function available.
AC_CACHE_CHECK([whether $CC accepts -pthread], [ac_cv_pthread],
[ac_save_cc="$CC"
CC="$CC -pthread"
AC_RUN_IFELSE([AC_LANG_SOURCE([[
#include <stdio.h>
#include <pthread.h>
void* routine(void* p){return NULL;}
int main(void){
pthread_t p;
if(pthread_create(&p,NULL,routine,NULL)!=0)
return 1;
(void)pthread_detach(p);
return 0;
}
]])],[ac_cv_pthread=yes],[ac_cv_pthread=no],[ac_cv_pthread=no])
CC="$ac_save_cc"])
fiwhere the key line is that third-to-last one: if the test program returns success, set If you want to play around with this in isolation, you can create a configure.ac file in an empty directory containing something likeAC_PREREQ([2.71])
AC_INIT([python],[3.14],[https://github.com/python/cpython/issues/])
AC_CACHE_CHECK([whether $CC accepts -pthread], [ac_cv_pthread],
[ac_save_cc="$CC"
CC="$CC -pthread"
AC_RUN_IFELSE([AC_LANG_SOURCE([[
#include <stdio.h>
#include <pthread.h>
void* routine(void* p){return NULL;}
int main(void){
pthread_t p;
if(pthread_create(&p,NULL,routine,NULL)!=0)
return 1;
(void)pthread_detach(p);
return 0;
}
]])],[ac_cv_pthread=yes],[ac_cv_pthread=no],[ac_cv_pthread=no])
CC="$ac_save_cc"])and then do $ autoconf
/usr/share/autoconf/autoconf/trailer.m4:4: warning: AC_OUTPUT was never used
$ ./configure
checking for gcc... gcc
checking whether the C compiler works... yes
checking for C compiler default output file name... a.out
checking for suffix of executables...
checking whether we are cross compiling... no
checking for suffix of object files... o
checking whether the compiler supports GNU C... yes
checking whether gcc accepts -g... yes
checking for gcc option to enable C11 features... none needed
checking whether gcc accepts -pthread... yes
$ ./configure cross_compiling=yes
checking for gcc... gcc
configure: WARNING: using cross tools not prefixed with host triplet
checking whether the C compiler works... yes
checking for C compiler default output file name... a.out
checking for suffix of executables...
checking whether we are cross compiling... yes
checking for suffix of object files... o
checking whether the compiler supports GNU C... yes
checking whether gcc accepts -g... yes
checking for gcc option to enable C11 features... none needed
checking whether gcc accepts -pthread... noIf you examine config.log in the latter case you'll see that no test was run (which is not surprising, this is the documented behavior). (Incidentally, doing I suspect this is also what was going on with python/cpython#128106, where we also got an unwanted ./configure result, and it looks like this was also an This is a little frustrating; there's probably several of these feature detections that we're losing on all cross targets, including the optimized variants. Ideally, what I would like to do is to make autoconf error out on any of these. If you leave off the last argument to For now, I guess I'll patch ./configure to assume that our compiler actually does support |
Also, switch to using cross_compiling=yes instead of patching ./configure in place, which allows us to move rerunning autoconf to right before running ./configure, avoiding the risk of patching ./configure.ac too late. See astral-sh#599.
Also, switch to using cross_compiling=yes instead of patching ./configure in place, which allows us to move rerunning autoconf to right before running ./configure, avoiding the risk of patching ./configure.ac too late. See #599.
I am getting CI failures on #592 on some variants because of missing pthread symbols because of a missing
-pthreadon the compiler command line. Compare, for instance, x86_64_v2-unknown-linux-gnu / 3.9 / debug which fails withversus x86_64-unknown-linux-gnu / 3.9 / debug which succeeds with the corresponding build line being
If you dig a bit earlier in the build logs, the x86_64_v2 (unsuccessful) build does
while the x86_64 (successful) build does
This does not appear to have been introduced by my PR; the same ./configure discrepancy happens on HEAD (compare this run and this run, for instance), though the fact that ./configure decides not to pass
-pthreaddoes not fail the build on HEAD. I do not know if it has any unwanted side effects.Almost certainly what is going on is that the test program is failing to run for some other reason, and ./configure is getting confused.
We need to resolve this as it blocks #592, and I'm a little bit uncomfortable with the fact that this discrepancy is happening and I'd like to think a bit about noticing and detecting discrepancies like this in the general case.
The text was updated successfully, but these errors were encountered: