openssl backend fails to import since 41.0.0

[felixonmars]

• Versions of Python, cryptography, cffi, pip, and setuptools
  you're using
  Python 3.11.3
  cryptography 41.0.0/41.0.1
  pip 23.1.2
  setuptools 67.8.0
  setuptools-rust 1.6.0
  openssl 3.1.1

• How you installed cryptography
  Building the Arch Linux package (I am the packager)

• Clear steps for reproducing your bug
  Since 41.0.0, I am getting the following error when trying to import the openssl backend:

>>> from cryptography.hazmat.backends.openssl import backend
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/usr/lib/python3.11/site-packages/cryptography/hazmat/backends/openssl/__init__.py", line 7, in <module>
    from cryptography.hazmat.backends.openssl.backend import backend
  File "/usr/lib/python3.11/site-packages/cryptography/hazmat/backends/openssl/backend.py", line 13, in <module>
    from cryptography import utils, x509
  File "/usr/lib/python3.11/site-packages/cryptography/x509/__init__.py", line 7, in <module>
    from cryptography.x509 import certificate_transparency
  File "/usr/lib/python3.11/site-packages/cryptography/x509/certificate_transparency.py", line 11, in <module>
    from cryptography.hazmat.bindings._rust import x509 as rust_x509
ImportError: /usr/lib/python3.11/site-packages/cryptography/hazmat/bindings/_rust.abi3.so: undefined symbol: PyInit__openssl

Which isn't the case for 40.0.2 or older versions with everything else unchanged. The package was built with a plain "python setup.py build" and the build went well.

[alex]

Does cryptography 40.0 work?

[felixonmars]

Yes. 40.0.0, 40.0.1 and 40.0.2 all work properly.

[reaperhulk]

I just pulled archlinux:latest on an x86_64 machine and built and ran all the tests via pip install ".[test]" (+ installing vectors) without any issues. Is it possible there's something specific about the packaging environment here?

Running python setup.py build also shows the following when I nm the resulting _rust.abi3.so:

0000000000164570 t PyInit__openssl

[alex]

Hmm, that's a bit perplexing, the only things I can imagine causing this were all changes that happened in 40.0, between 40.0 and 41.0 there weren't any substantial changes to our build process that I can think of (or that a brief perusal of the diff turned up).

[felixonmars]

I just pulled archlinux:latest on an x86_64 machine and built and ran all the tests via pip install ".[test]" (+ installing vectors) without any issues. Is it possible there's something specific about the packaging environment here?

Indeed that is the case. I have just figured out that LTO is what makes the issue appears. The problem only reproduces with -flto=auto set and 41.0.0+.

[alex]

That's a head-scratcher. I guess lto is deleting the function for some reason, even though there's a direct call to it from Rust?

[felixonmars]

Comparing the nm output indicates that all openssl and cffi symbols were removed by LTO, too.
nm_diff.txt

[alex]

The only change we made between 40.0 and 41.0 that might effect this: in 40.0, the crate that links against the compiled cffi module is the root crate, but in 41.0 it's another crate (which the root crate depends on).

I don't know why that matters, but I'm sure it's the cause. I also don't understand how to fix it.

[felixonmars]

As pointed out by @liushuyu (Thanks!), using GCC's LTO on the C/C++ side with LLVM's LTO on the Rust side is known to have compatibility issues.

I have updated Arch's PKGBUILD to use clang and lld respectively, and the problem did go away even with LTO still turned on.

It might be a good idea if setuptools-rust or cryptography would default to use clang/lld when available, though. I am currently supplying CC=clang RUSTFLAGS="-Clinker-plugin-lto -Clinker=clang -Clink-arg=-fuse-ld=lld" as envvars.

[alex]

Hmm, on the one hand, this is miserable to debug. On the other hand using something other than the default system compiler seems like very surprising behavior.

[mgorny]

One of Gentoo users his this problem too: https://bugs.gentoo.org/903908

[alex]

I wonder if the appropriate fix is in the cc create, to have it reject -flto, since as I understand it, that will never work with rustc?

[liushuyu]

I wonder if the appropriate fix is in the cc create, to have it reject -flto, since as I understand it, that will never work with rustc?

It will work with rustc if the C/C++ compiler is Clang (sharing the same code generator, LLVM). And will have issues when LTO is enabled, but the compilers use different code-generation facilities.

[alex]

Yes, you're right I should have been more precise. Though, AFAIK, it can also fail with clang, if clang and rustc are using different versions of LLVM.

[matoro]

I can confirm that this is due to GCC's LTO, and is also platform-independent as I observed it on PowerPC.