Created attachment 493704 [details] build.log ... powerpc64-unknown-linux-gnu-gcc -shared -Wl,-O1 -Wl,--as-needed -Wl,--hash-style=gnu -O2 -pipe -fdiagnostics-show-option -frecord-gcc-switches /dev/shm/portage/dev-python/cryptography-2.0.3/w ork/cryptography-2.0.3-python3_4/temp.linux-ppc64-3.4/dev/shm/portage/dev-python/cryptography-2.0.3/work/cryptography-2.0.3-python3_4/temp.linux-ppc64-3.4/_openssl.o -L/usr/lib64 -lssl -lcryp to -lpython3.4m -o /dev/shm/portage/dev-python/cryptography-2.0.3/work/cryptography-2.0.3-python3_4/lib/cryptography/hazmat/bindings/_openssl.abi3.so ... >>> Source compiled. >>> Test phase: dev-python/cryptography-2.0.3 * python2_7: running distutils-r1_run_phase python_test python-exec: Invalid impl in /etc/python-exec/python-exec.conf: python3.2 * Unable to trace static ELF: /sbin/ldconfig: /sbin/ldconfig -p * Unable to trace static ELF: /sbin/ldconfig: /sbin/ldconfig -p Traceback (most recent call last): File "/usr/lib64/python2.7/site-packages/_pytest/config.py", line 373, in _importconftest mod = conftestpath.pyimport() File "/usr/lib64/python2.7/site-packages/py/_path/local.py", line 662, in pyimport __import__(modname) File "/usr/lib64/python2.7/site-packages/_pytest/assertion/rewrite.py", line 215, in load_module py.builtin.exec_(co, mod.__dict__) File "/usr/lib64/python2.7/site-packages/py/_builtin.py", line 221, in exec_ exec2(obj, globals, locals) File "<string>", line 7, in exec2 File "/dev/shm/portage/dev-python/cryptography-2.0.3/work/cryptography-2.0.3/tests/conftest.py", line 9, in <module> from cryptography.hazmat.backends.openssl import backend as openssl_backend File "/dev/shm/portage/dev-python/cryptography-2.0.3/work/cryptography-2.0.3-python2_7/lib/cryptography/hazmat/backends/openssl/__init__.py", line 7, in <module> from cryptography.hazmat.backends.openssl.backend import backend File "/dev/shm/portage/dev-python/cryptography-2.0.3/work/cryptography-2.0.3-python2_7/lib/cryptography/hazmat/backends/openssl/backend.py", line 53, in <module> from cryptography.hazmat.bindings.openssl import binding File "/dev/shm/portage/dev-python/cryptography-2.0.3/work/cryptography-2.0.3-python2_7/lib/cryptography/hazmat/bindings/openssl/binding.py", line 13, in <module> from cryptography.hazmat.bindings._openssl import ffi, lib ImportError: /dev/shm/portage/dev-python/cryptography-2.0.3/work/cryptography-2.0.3-python2_7/lib/cryptography/hazmat/bindings/_openssl.so: undefined symbol: pthread_atfork ERROR: could not load /dev/shm/portage/dev-python/cryptography-2.0.3/work/cryptography-2.0.3/tests/conftest.py
Created attachment 493706 [details] emerge --info
I have exactly the same issue on arm.
Any solutions or workarounds? I have the same problem on ARM64.
On AMD64, libpthread gets pulled in by libpython. Is this somehow not the case on ARM64?
Not sure if it helps, but this is the situation on my ARM system (armv7a-hardfloat-linux-gnueabi): glibc-2.23-r4: ls -l /lib/libpthread.so.0 /lib/libpthread.so.0 -> libpthread-2.23.so nm /lib/libpthread-2.23.so |grep atfork (nothing returned) nm /usr/lib/libpthread_nonshared.a pthread_atfork.oS: w __dso_handle U _GLOBAL_OFFSET_TABLE_ 00000000 T __pthread_atfork 00000000 T pthread_atfork U __register_atfork python-2.7.12: ldd /usr/bin/python2.7 libpython2.7.so.1.0 => /usr/lib/libpython2.7.so.1.0 (0xb6dcd000) libpthread.so.0 => /lib/libpthread.so.0 (0xb6dad000) libc.so.6 => /lib/libc.so.6 (0xb6c82000) libdl.so.2 => /lib/libdl.so.2 (0xb6c77000) libutil.so.1 => /lib/libutil.so.1 (0xb6c6b000) libm.so.6 => /lib/libm.so.6 (0xb6bf6000) /lib/ld-linux-armhf.so.3 (0xb6f57000) So, libpthread.so.0 is pulled in by python but for some reason this shared library does not contain pthread_atfork. On AMD64 I have: nm /lib/libpthread-2.23.so |grep atfork 000000000000e6b0 t __dyn_pthread_atfork 000000000000e6b0 T pthread_atfork@GLIBC_2.2.5 U __register_atfork@@GLIBC_2.3.2 pthread_atfork is also present in /usr/lib/libpthread_nonshared.a . (In reply to Mike Gilbert from comment #4) > On AMD64, libpthread gets pulled in by libpython. Is this somehow not the > case on ARM64?
Yes, I think it's precisely the issue. CFLAGS should contain -pthread to pull non-shared part explicitly.
(In reply to Sergei Trofimovich from comment #6) > Yes, I think it's precisely the issue. CFLAGS should contain -pthread to > pull non-shared part explicitly. s/CFLAGS/LDFLAGS/
Strangely, when I build this manually (outside of an ebuild), -pthread gets added automatically. We'll need to figure out why that is getting lost in the ebuild environment.
It looks like this is happening because we export the CC variable in the ebuild environment. This overrides the default python CC config var, which contains "-pthread".
The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=c824d1c44fcf4556de21d2c8b8ae3732b0fc0c5b commit c824d1c44fcf4556de21d2c8b8ae3732b0fc0c5b Author: Mike Gilbert <floppym@gentoo.org> AuthorDate: 2017-10-09 21:32:32 +0000 Commit: Mike Gilbert <floppym@gentoo.org> CommitDate: 2017-10-09 21:33:06 +0000 dev-python/cryptography: append -pthread to CFLAGS This works around some weird distutils behavior when CC is set in the environment. Bug: https://bugs.gentoo.org/630578 Package-Manager: Portage-2.3.11_p4, Repoman-2.3.3_p62 dev-python/cryptography/cryptography-2.0.3.ebuild | 6 +++++- 1 file changed, 5 insertions(+), 1 deletion(-)}
Please test and close the bug if all is well.
I'm not the reporter, but it solved the problem for me on arm.
Adding -pthread to my CFLAGS works for me, too, on -march=armv6j.
Pases tests on ppc/ppc64 now. Thank you!
