Bug: Linker failure: undefined OpenSSL symbols in extension_installer.cpp.o on aarch64-unknown-linux-gnu — lbug v0.17.1 and v0.18.0

[jmurphyq]

Ladybug version

v0.18.0

What operating system are you using?

MacOS 26.5.2

What happened?

Summary

cargo build --release fails at link time with undefined reference to 'SSL_ctrl' (and ~40 other OpenSSL symbols) when building a crate that depends on lbug targeting aarch64-unknown-linux-gnu. Confirmed on both v0.17.1 and v0.18.0 — the OpenSSL fixes landed in 0.18.0 (#579, LadybugDB/ladybug#581, LadybugDB/ladybug#590) did not address this code path. The compilation phase completes successfully — all crates compile, liblbug.a is produced — but the final link step fails because the linker is never told to pull in -lssl and -lcrypto.

The C++ object extension_installer.cpp.o inside liblbug.a uses httplib::SSLClient (compiled with CPPHTTPLIB_OPENSSL_SUPPORT), which references OpenSSL symbols at link time. On x86_64 this appears to resolve correctly; on aarch64 the flags are not emitted and the build fails unconditionally.

Environment

lbug version	0.17.1 and 0.18.0 (both confirmed)
Rust target	aarch64-unknown-linux-gnu and aarch64-apple-darwin (both confirmed)
Rust toolchain	rust:1.95-slim-bookworm (Docker, --platform=linux/arm64); also reproduced natively on macOS
Build OS	Debian 12 (bookworm) ARM64 (Docker); macOS Apple Silicon (native)
OpenSSL	libssl-dev 3.0.20-1~deb12u2 (Linux); system OpenSSL (macOS)
Host	macOS (Apple Silicon), Docker Desktop — native ARM64 build

Minimal reproduction

Add lbug = "0.18.0" to any Cargo.toml, then build for ARM64 (also reproducible with 0.17.1):

FROM --platform=linux/arm64 rust:1.95-slim-bookworm AS builder

RUN apt-get update && apt-get install -y --no-install-recommends \
    pkg-config libssl-dev build-essential cmake

WORKDIR /build
COPY Cargo.toml Cargo.lock ./
COPY src/ src/

RUN cargo build --release

Observed:

error: linking with `cc` failed: exit status: 1
  = note: /usr/bin/ld: /build/target/release/deps/.../liblbug.a(extension_installer.cpp.o):
          undefined reference to `SSL_ctrl'
  = note: /usr/bin/ld: ...undefined reference to `SSL_CTX_new'
  = note: /usr/bin/ld: ...undefined reference to `SSL_CTX_free'
  ... (~40 further OpenSSL symbol errors) ...
  = note: collect2: error: ld returned 1 exit status

All undefined symbols originate from extension_installer.cpp.o inside liblbug.a — the httplib::SSLClient code path.

Workaround (in .cargo/config.toml):

[target.aarch64-unknown-linux-gnu]
rustflags = ["-lssl", "-lcrypto"]

This unblocks the build, confirming the only missing piece is the link flag emission.

Impact

Any crate depending on lbug cannot be built for ARM64 at all — confirmed on both aarch64-unknown-linux-gnu (Debian bookworm in Docker) and aarch64-apple-darwin (macOS Apple Silicon, native build). The build fails unconditionally with no path forward other than the .cargo/config.toml workaround above. Consumers deploying to ARM64 ECS (Fargate Graviton) or building natively on Apple Silicon are blocked.

Questions / possible leads

• lbug's build.rs presumably uses cxx or cc to compile extension_installer.cpp. For OpenSSL-linked C++ code, the build script should emit cargo:rustc-link-lib=ssl and cargo:rustc-link-lib=crypto. Are these emitted conditionally on target arch, or is the ARM64 code path simply missing them?
• Does the x86_64 build succeed because of a different link ordering or because some other dependency in the graph happens to pull in -lssl transitively on that platform?
• Would disabling CPPHTTPLIB_OPENSSL_SUPPORT for the extension installer be an option if HTTPS extension repos are not needed in embedded/server builds?

Are there known steps to reproduce?

No response

[adsharma]

Adding -lssl -lcrypto is the correct fix. I'm fixing up a few other places. Will get to this once I'm done.

Or you can propose a PR on ladybug-rust repo

[jmurphyq]

The fix in PR #21 (pkg-config --variable=libdir openssl) is incomplete on macOS.

Problem: Homebrew commonly has both openssl@1.1 and openssl@3 installed. Formulae
that depend on 1.1 (e.g. mysql-client) append openssl@1.1/lib/pkgconfig to
PKG_CONFIG_PATH, so the unversioned pkg-config openssl silently resolves to 1.1.
liblbug.a is compiled against OpenSSL 3 and uses SSL_get1_peer_certificate (an
OpenSSL 3 API not present in 1.1), so the link still fails.

Stock macOS is not a fallback: Apple ships LibreSSL 3.3.6, not OpenSSL, and there are
no linkable libssl/libcrypto in /usr/lib at all. So on macOS, OpenSSL 3 must come
from an external package manager — the pkg-config openssl path cannot be trusted to
find the right version there.

Suggested fix: use the openssl-sys crate as a [build-dependencies] entry. It
handles macOS Homebrew lookup, respects OPENSSL_ROOT_DIR, disambiguates 1.1 vs 3,
verifies the version, and emits the correct link directives on all platforms.