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?
|
➜
