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

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 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 audit tool suggested a version that the author later yanked, and cargo refuses to build it. Pick the nearest non-yanked version (check yank status on the registry first), update the lockfile, and re-run the audit.

Error

agent's cargo audit fix picked a yanked version  -  the build failed on 'version X has been yanked'

Steps

1. Confirm the yank: check the version's status on the registry page for the crate. Expected output: The version is marked yanked, explaining the build failure.

2. Choose the nearest non-yanked version that still addresses the advisory, preferring the smallest move that fixes it. Expected output: A concrete replacement version.

3. Run cargo update -p [crate name] --precise [version] and rebuild. Expected output: The build succeeds and the lockfile pins the non-yanked version.

4. Re-run cargo audit to confirm the advisory is resolved by the replacement. Expected output: No open advisory for the crate.

5. Add a yank check to the agent's fix flow: verify registry status before committing an audit-suggested version. Expected output: The next suggested version is validated before it lands.

When to use

• cargo fails with version X has been yanked after an audit fix
• An automated tool pinned a version the registry no longer serves
• You are hardening an agent's audit-fix workflow

When not to use

• A deliberately yanked-version dependency you need to keep; vendor or fork it
• Audit advisories with no fixed version; that is triage, not a yank problem
• Network or registry outages blocking downloads

Variant phrasings

cargo build fails version has been yanked after update

cargo audit suggested a yanked version

replace yanked crate version in Cargo.lock

Why it happens

Yank status is metadata the audit tool may not have checked when it suggested the version. Between the suggestion and the build, or even before it, the author yanked that version, and cargo treats yanked versions as uninstallable for new lockfiles.

Edge cases

• If your existing lockfile already pins the yanked version, builds keep working until the lockfile changes; the failure appears exactly when you touch it.
• A yanked version can still be the only fix for an advisory; then you need a fork, a patch section, or an exception.
• Audit databases lag yank events; re-check status at apply time, not at suggestion time.

Provenance

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

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

Thread query: agent's cargo audit fix picked a yanked version - the build failed on 'version X has been yanked'

TL;DR: The audit tool suggested a version that the author later yanked, and cargo refuses to build it. Pick the nearest non-yanked version (check yank status on the registry first), update the lockfile, and re-run the audit.