From 6b5c8af1c8b48c7b75f1c82577ec824453305604 Mon Sep 17 00:00:00 2001 From: Ryan Hartman Date: Sun, 2 Aug 2026 21:03:59 -0600 Subject: [PATCH] Pin OpenSSL libdir so the bundled Python finds it (#15047) On Linux the bundled CPython silently links the system OpenSSL instead of the one built in deps/, and the dependency build then fails: install: cannot stat 'Modules/_ssl.cpython-312-x86_64-linux-gnu.so': No such file or directory The chain: * OpenSSL's linux-x86_64 target sets multilib=64, so 'make install_sw' installs the static libs to /lib64 while every other dependency in the prefix uses /lib. * CPython's --with-openssl= only ever emits -L/lib. It does not look in lib64, so -lssl resolves to the system OpenSSL. * gcc -shared does not error on unresolved symbols, so the link appears to succeed. _ssl.c was compiled against the bundled 1.1.1w headers, which map SSL_get1_peer_certificate onto the pre-3.0 SSL_get_peer_certificate -- a symbol OpenSSL 3.x removed. The module then fails to import: _ssl failed to import: undefined symbol: SSL_get_peer_certificate Could not build the ssl module! * With no _ssl built, 'make install' cannot stat it and the build stops. Passing --libdir=lib keeps the prefix single-layout, so CPython's -L/lib finds the bundled static libraries and links against the headers it was compiled with. CMake-based dependencies were unaffected throughout, because CMake's FindOpenSSL searches lib64 on its own; only CPython's autoconf path is sensitive to this. Affects any distribution where OpenSSL selects the lib64 layout, which is the Fedora, openSUSE and Arch families. Debian and Ubuntu are unaffected, which is why CI has not seen it. Verified on Arch (GCC 16.1.1, CMake 4.4.2): the dependency build completes and the bundled interpreter reports the bundled OpenSSL rather than the system one: $ deps/build/OrcaSlicer_dep/usr/local/libpython/bin/python3.12 \ -c 'import ssl; print(ssl.OPENSSL_VERSION)' OpenSSL 1.1.1w 11 Sep 2023 Not verified on macOS or Windows. The flag is accepted by OpenSSL's Configure on all platforms and Darwin targets do not set multilib, so it should be a no-op there, but CI is the check. --- deps/OpenSSL/OpenSSL.cmake | 8 ++++++++ 1 file changed, 8 insertions(+) diff --git a/deps/OpenSSL/OpenSSL.cmake b/deps/OpenSSL/OpenSSL.cmake index 21a49b91b8..e43997265b 100644 --- a/deps/OpenSSL/OpenSSL.cmake +++ b/deps/OpenSSL/OpenSSL.cmake @@ -52,6 +52,14 @@ ExternalProject_Add(dep_OpenSSL CONFIGURE_COMMAND ${_conf_cmd} ${_cross_arch} "--openssldir=${DESTDIR}" "--prefix=${DESTDIR}" + # OpenSSL's linux-x86_64 target sets multilib=64, so it installs to + # /lib64 while every other dep uses /lib. CPython's + # --with-openssl only ever emits -L/lib, so it misses the bundled + # static libs and silently links the system OpenSSL instead -- which, + # against 1.1.1w headers, leaves _ssl.so with an undefined + # SSL_get_peer_certificate (removed in OpenSSL 3.x). Pin libdir so the + # prefix stays single-layout. + "--libdir=lib" ${_cross_comp_prefix_line} no-shared no-asm