I'm cross-compiling python to ARM, following instructions from the crossenv project @ https://crossenv.readthedocs.io/en/latest/quickstart.html#build-or-obtain-host-python

I was getting pthread related errors when using cross-built extension modules. I realized the issue was that distutils wasn't passing -pthread to gcc.

On my native python (Fedora 32 Python 3.8):

>>> import pprint, distutils.sysconfig
>>> pprint.pprint({i: distutils.sysconfig.get_config_vars(i)[0] for i in ('CC', 'CXX', 'LDSHARED')})
{'CC': 'gcc -pthread',
 'CXX': 'g++ -pthread',
 'LDSHARED': 'gcc -pthread -shared -Wl,-z,relro -Wl,--as-needed  -Wl,-z,now  '
             '-g  -Wl,-z,relro -Wl,--as-needed  -Wl,-z,now  -g'}

In my cross-compiled python environment:

>>> import pprint, distutils.sysconfig
>>> pprint.pprint({i: distutils.sysconfig.get_config_vars(i)[0] for i in ('CC', 'CXX', 'LDSHARED')})
{'CC': 'arm-frc2020-linux-gnueabi-gcc',
 'CXX': 'arm-frc2020-linux-gnueabi-c++',
 'LDSHARED': 'arm-frc2020-linux-gnueabi-gcc -shared'}

As you can see, no -pthread flag. I went digging in the configure script and found this comment in configure.ac:2110:

# 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.

... well, that doesn't work when cross-compiling. I looked at some other variables set to override things for cross compiling, and tried adding "ac_cv_pthread_is_default=no ac_cv_pthread=yes ac_cv_cxx_thread=yes" to my cross-compile ./configure, and it's closer:

>>> import pprint, distutils.sysconfig
>>> pprint.pprint({i: distutils.sysconfig.get_config_vars(i)[0] for i in ('CC', 'CXX', 'LDSHARED')})
{'CC': 'arm-frc2020-linux-gnueabi-gcc -pthread',
 'CXX': 'arm-frc2020-linux-gnueabi-c++',
 'LDSHARED': 'arm-frc2020-linux-gnueabi-gcc -pthread -shared'}

Closer, but not there yet! It appears that the $ac_cv_cxx_thread is not externally settable (unlike ac_cv_pthread), which I guess is because it's not wrapped in a AC_CACHE_VAL macro?

It seems that the right fix would be for someone to use AC_CACHE_VAL to allow $ac_cv_cxx_thread to be set externally? I'm happy to cargo cult some code from other parts of configure.ac and make a PR for it, but it's not immediately clear (a) what bad side effects this could cause and (b) what the best mechanism to use to regenerate configure et al is?