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?

FWIW, I've been using the patch in my PR and it seems to work.

thanks!