fix(musl): vendor openssl for musl targets

daytona-sdk transitively pulls native-tls via reqwest (its own
reqwest v0.12, separate from our rustls-configured workspace
reqwest v0.13). native-tls requires libssl headers at build time,
which musl-gcc cannot satisfy from the host's glibc libssl-dev.

Add a target-specific openssl dep with the vendored feature so
openssl-sys compiles openssl from source for musl builds. glibc
builds are unaffected — they continue to link against the system
libssl that CI runners already have.

Verified end-to-end: aarch64-unknown-linux-musl binary built locally
runs on Alpine 3.20 (pure musl userspace).

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
This commit is contained in:
Bryan Helmkamp 2026-04-18 01:14:02 -04:00
parent 2f2f14562d
commit b8ce415551
No known key found for this signature in database

View file

@ -92,6 +92,12 @@ tokio-util.workspace = true
[target.'cfg(target_os = "macos")'.dependencies]
core-foundation = { version = "0.9", optional = true }
# Vendor openssl only for musl targets. daytona-sdk transitively pulls
# native-tls via reqwest, which needs libssl. On glibc runners the system
# libssl is used; on musl runners we compile openssl from source.
[target.'cfg(target_env = "musl")'.dependencies]
openssl = { version = "0.10", features = ["vendored"] }
[build-dependencies]
chrono = { workspace = true }