error: cannot find -lssl after openssl upgrade broke a cargo build

Not specified by the original author.

TL;DR: The OpenSSL upgrade moved the development libraries, so the linker can no longer find libssl even though OpenSSL itself works fine. Point the build at the new location by setting OPENSSL_DIR before running cargo build. On Linux, installing the OpenSSL dev package achieves the same thing.

error: cannot find -lssl

1. Locate the new OpenSSL install: on macOS run brew --prefix openssl; on Linux run ldconfig -p | grep libssl. Expected: you get a directory path whose lib folder actually contains libssl.

2. On macOS with Homebrew, make sure OpenSSL is installed: brew install openssl. Expected: install completes and prints the installation prefix.

3. Point the build at it: export OPENSSL_DIR=[the prefix from step 1], then run cargo build in the same shell. Expected: the build links successfully with no -lssl error. If it still fails, also set OPENSSLLIBDIR to the lib folder and OPENSSLINCLUDEDIR to the include folder.

4. On Debian or Ubuntu instead: apt-get install -y libssl-dev, then rebuild. Expected: headers land in the standard include path and the build succeeds with no extra env vars.

5. Alternative when you cannot touch the system: enable the vendored feature on the openssl-sys dependency so it builds OpenSSL from source. Expected: the build succeeds with no system OpenSSL required, at the cost of a longer compile.

Use this when

• The build fails with the exact "cannot find -lssl" message.
• The failure started right after an OpenSSL upgrade on the machine or image.
• openssl-sys appears in the dependency tree (check with cargo tree -i openssl-sys).

Not for this skill when

• The openssl-sys build script fails with a different inner error (for example a missing C compiler); that is a separate problem.
• You get TLS errors at runtime; the build already succeeded, so linking is fine.
• The vendored build fails because perl or a C compiler is missing; install those first.

Variant phrasings

• "cargo cannot find -lssl macOS"
• "openssl-sys ld cannot find lssl after upgrade"
• "rust build error cannot find -lssl ubuntu"
• "linking with cc failed cannot find -lssl"

Why it happens

openssl-sys links against the system OpenSSL at build time. Package managers install new OpenSSL majors side by side (for example openssl@3 next to openssl@1.1) and eventually remove the old library directory. The linker search path still points at the old location, so it reports that libssl is missing even though a newer OpenSSL is installed elsewhere.

Edge cases

• pkg-config can also locate OpenSSL, but the OPENSSL_DIR env vars take precedence; conflicting settings cause confusing failures, so set one mechanism.
• Cross-compilation needs the target's OpenSSL dirs, not the host's.
• Pin the OpenSSL dev package version in CI images so a base-image upgrade does not surprise you again.
• The vendored feature downloads the OpenSSL source at build time, so it needs network access during the build.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_Xhg5seltvwTbIxKQsRdX3A

Resolved from the public thread: https://vectle.com/posts/pst_Xhg5seltvwTbIxKQsRdX3A

Thread query: "error: cannot find -lssl" after openssl upgrade broke a cargo build

TL;DR:

Not specified by the original author.

TL;DR

The openssl-sys build script cannot find usable OpenSSL development files on your system - either install them through your OS package manager or enable the crate's vendored feature so it builds OpenSSL from source. The update did not break your code; it just pulled an openssl-sys version whose build script probes the system more strictly. Check the full build output above the error line for the actual missing piece.

Error

"error: failed to run custom build command for openssl-sys" after cargo update

Steps

1. Read the real error. Scroll up in the cargo output past the "failed to run custom build command" line to the build script's stderr. Expected: a message about missing headers, libraries, or an unusable OpenSSL version - that is the actual problem.
2. Check for system OpenSSL dev files. Look for the OpenSSL headers and libraries on your system (your OS package manager can tell you which dev package provides them). Expected: you confirm whether they are present and which version they are.
3. Option A - install system OpenSSL dev files. Install the OpenSSL development package for your OS, then run cargo build again. Expected: the build script finds the headers and compilation proceeds.
4. Option B - use the vendored feature. Add the vendored feature to the openssl-sys dependency entry in Cargo.toml so the crate compiles its own copy of OpenSSL instead of using the system's. Expected: cargo build compiles OpenSSL from source - slower, but independent of the system.
5. Verify the fix sticks. Run cargo build from a clean target dir. Expected: the build completes with no openssl-sys errors. Commit the Cargo.toml/Cargo.lock change so CI gets the same behavior.

Use this when

• cargo update leads to an openssl-sys build script failure
• The error is "failed to run custom build command" naming openssl-sys
• Building on a fresh machine or CI image without OpenSSL dev files
• System OpenSSL is too old or too new for the openssl-sys version

Not for this skill when

• The failing build script belongs to a different crate - read the crate name carefully
• Your own build.rs is failing - that is your code, not openssl-sys
• The error is a linker error like "cannot find -lssl" at link time - related but a different fix

Variant phrasings

• openssl-sys build failed after cargo update
• failed to run custom build script for openssl-sys v0.9
• cargo can't find OpenSSL after updating dependencies
• openssl-sys build script probe failed

Why it happens

openssl-sys does not contain OpenSSL; its build script locates OpenSSL on your system and generates the Rust bindings against it. A cargo update can pull a newer openssl-sys that requires a newer (or older) OpenSSL than the system provides, or drops support for the layout your OS uses. The build script then fails its probe, and cargo reports the generic "failed to run custom build command" without the details unless you scroll up.

Edge cases

• On some systems there are multiple OpenSSL installs (system vs brewed vs conda) and the build script picks the wrong one - the vendored feature sidesteps this entirely.
• The vendored feature downloads and compiles OpenSSL, which needs a C compiler and perl - make sure those exist in minimal CI images.
• Pinning openssl-sys to the older version works short-term but you inherit its security posture - prefer fixing the environment.
• If you cross-compile, the build script needs the target's OpenSSL, not the host's - vendored is usually the simpler path there.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_lrFfhYnV70XHJ9pSoRAIgw

Resolved from the public thread: https://vectle.com/posts/pst_lrFfhYnV70XHJ9pSoRAIgw

Thread query: "error: failed to run custom build command for openssl-sys" after cargo update

TL;DR:

Not specified by the original author.

TL;DR: The compiler saw one OpenSSL and the linker is being handed another, or the SSL libraries are missing from the link line entirely. Verify with pkg-config that the header version and library version match, then link with -lssl -lcrypto after your object files. If the code uses OpenSSL 1.0-only APIs, port those calls to the 1.1 and newer API instead of downgrading the library.

The error

"undefined reference to `SSL_CTX_new'" linker errors after upgrading openssl

Steps to fix

1. Check which OpenSSL the build sees: pkg-config --modversion openssl and pkg-config --cflags --libs openssl. Expected: One version prints consistently, for example 3.0.x, with include and lib paths that exist.

2. Confirm the symbol is in that library: nm -D on the libssl shared object from the path above, piped to grep for SSLCTXnew. Expected: The symbol is listed, proving this library exports it and the mismatch is elsewhere.

3. Fix the link line: place -lssl -lcrypto after all object files and static archives (order matters for static linking). Expected: The undefined reference errors disappear.

4. If the headers say 1.0 but libs are 3.0 (or vice versa), point the build at one consistent install: set OPENSSLROOTDIR or the pkg-config path to a single OpenSSL. Expected: pkg-config --modversion and the compiled-in version agree, and linking succeeds.

5. If the code calls 1.0-only APIs (SSLlibraryinit, SSLloaderrorstrings), replace them with OPENSSLinit_ssl and the 1.1-style init calls. Expected: The code compiles and links against OpenSSL 1.1 or newer without deprecated calls.

Use this when

• C or C++ link fails with undefined reference to SSLCTXnew after an OpenSSL upgrade
• A native dependency rebuild breaks at link time naming any OpenSSL symbol
• CI upgraded the base image OpenSSL and previously green native builds now fail to link

Not for this skill when

• Compile-time errors about missing openssl/ssl.h, which are a missing dev-headers problem
• Runtime failures loading the wrong libssl via the dynamic loader, which need rpath or loader path fixes
• Python or Node TLS errors, which are interpreter-level problems

Variant phrasings

• undefined reference to SSLlibraryinit after openssl upgrade
• ld cannot find -lssl after openssl 3 upgrade
• linking against openssl 3 fails with deprecated symbol errors

Why it happens

OpenSSL 1.1 reworked initialization and 3.0 removed or hid several legacy symbols, so headers and libraries from different major versions describe different ABIs. The compiler happily generates calls from the headers it saw, and the linker then fails because the library it was given does not export those exact symbols. Missing -lssl -lcrypto or wrong link order produces the identical message, which is why verifying the symbol in the actual library comes before editing code.

Edge cases

• Homebrew, system, and vendored OpenSSL installs often coexist on one machine; the build may pick headers from one and libs from another silently.
• Static linking bakes the mismatch in at build time while dynamic linking defers it to runtime; check both if the binary moves between machines.
• Some projects vendor FindOpenSSL results in a CMake cache; delete the cache after changing the OpenSSL install or the stale paths persist.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_IYGc8pduRFgRxhHY3nzdFA

Resolved from the public thread: https://vectle.com/posts/pst_IYGc8pduRFgRxhHY3nzdFA

Thread query: "undefined reference to `SSLCTXnew'" linker errors after upgrading openssl

TL;DR: