[GH-ISSUE #1534] Cross compilation fails because of missing system library `openssl`

kerem commented

2026-02-27 19:32:00 +03:00

Owner

Originally created by @pejobo on GitHub (Aug 13, 2025).
Original GitHub issue: https://github.com/librespot-org/librespot/issues/1534

Description

Following the wiki for cross compliation (on branch dev) fails with:

The system library `openssl` required by crate `openssl-sys` was not found

Version

Dev branch, commit c4766ceb996f805ce85c710ddac5fd1533bac3f5

How to reproduce

Check out dev + follow the steps outlined here: https://github.com/librespot-org/librespot/wiki/Cross-compiling

Log

  Could not find directory of OpenSSL installation, and this `-sys` crate cannot
  proceed without this knowledge. If OpenSSL is installed and this crate had
  trouble finding it,  you can set the `OPENSSL_DIR` environment variable for the
  compilation process.

  Make sure you also have the development packages of openssl installed.
  For example, `libssl-dev` on Ubuntu or `openssl-devel` on Fedora.

  If you're in a situation where you think the directory *should* be found
  automatically, please open a bug at https://github.com/sfackler/rust-openssl
  and include information about your system as well as this message.

  $HOST = x86_64-unknown-linux-gnu
  $TARGET = arm-unknown-linux-gnueabihf
  openssl-sys = 0.9.109

Originally created by @pejobo on GitHub (Aug 13, 2025). Original GitHub issue: https://github.com/librespot-org/librespot/issues/1534 ### Description Following the wiki for cross compliation (on branch `dev`) fails with: ``` The system library `openssl` required by crate `openssl-sys` was not found ``` ### Version Dev branch, commit `c4766ceb996f805ce85c710ddac5fd1533bac3f5` ### How to reproduce Check out dev + follow the steps outlined here: https://github.com/librespot-org/librespot/wiki/Cross-compiling ### Log ``` Could not find directory of OpenSSL installation, and this `-sys` crate cannot proceed without this knowledge. If OpenSSL is installed and this crate had trouble finding it, you can set the `OPENSSL_DIR` environment variable for the compilation process. Make sure you also have the development packages of openssl installed. For example, `libssl-dev` on Ubuntu or `openssl-devel` on Fedora. If you're in a situation where you think the directory *should* be found automatically, please open a bug at https://github.com/sfackler/rust-openssl and include information about your system as well as this message. $HOST = x86_64-unknown-linux-gnu $TARGET = arm-unknown-linux-gnueabihf openssl-sys = 0.9.109 ```

kerem

2026-02-27 19:32:00 +03:00

closed this issue
added the
bug

dependencies
labels

kerem commented

2026-02-27 19:32:01 +03:00

Author

Owner

@pejobo commented on GitHub (Aug 13, 2025):

Installing libssl-dev to the container (for every arch variants) fixes this.

@pejobo commented on GitHub (Aug 13, 2025): Installing `libssl-dev` to the container (for every arch variants) fixes this.

kerem commented

2026-02-27 19:32:01 +03:00

Author

Owner

@roderickvd commented on GitHub (Aug 13, 2025):

I'm taking the hopefully popular decision to move away from AWS-LC and back to ring again. This removes the need for OpenSSL entirely, and make cross-platform compilation even simpler.

Did so in fe7ca0d700. Going to close this when the build passes.

Let me know if I'm missing something why we should keep AWS-LC.

@roderickvd commented on GitHub (Aug 13, 2025): I'm taking the hopefully popular decision to move away from AWS-LC and back to ring again. This removes the need for OpenSSL entirely, and make cross-platform compilation even simpler. Did so in fe7ca0d7009c59d3189d1682154ad63a8fb71332. Going to close this when the build passes. Let me know if I'm missing something why we should keep AWS-LC.

kerem commented

2026-02-27 19:32:01 +03:00

Author

Owner

@roderickvd commented on GitHub (Aug 13, 2025):

Because it's opinionated hour, I've also moved from native to webpki certificates on all platforms in 056d125.

@roderickvd commented on GitHub (Aug 13, 2025): Because it's opinionated hour, I've also moved from native to webpki certificates on all platforms in 056d125.

kerem commented

2026-02-27 19:32:01 +03:00

Author

Owner

@roderickvd commented on GitHub (Aug 13, 2025):

CI is passing again. Thanks for the report.

@roderickvd commented on GitHub (Aug 13, 2025): CI is passing again. Thanks for the report.

kerem commented

2026-02-27 19:32:01 +03:00

Author

Owner

@jirutka commented on GitHub (Aug 14, 2025):

I'm taking the hopefully popular decision to move away from AWS-LC and back to ring again.

Why did you use AWS-LC in the first place? The de-facto standard TLS library on Linux is OpenSSL; AWS-LC is just some corporate fork of OpenSSL.

Do I understand correctly that @pejobo didn’t realise that, when building with native TLS (which is optional, isn’t it?), he needs to install the native libraries (libssl-dev), and that you are using this as a reason to stop supporting native TLS? Or what is this about?

Because it's opinionated hour, I've also moved from native to webpki certificates on all platforms in github.com/librespot-org/librespot@056d125cb2.

Do you know what this means?! You are bundling all the root certificates with your binary! Do you understand all the implications of this? And why do you even want to do that?
Now I have to patch librespot in all packages that use this library, which is complicated by the rigidity of Cargo. So I would rather remove them from the distribution because I’m really fed up with this approach of Rust community.

@jirutka commented on GitHub (Aug 14, 2025): > I'm taking the hopefully popular decision to move away from AWS-LC and back to ring again. Why did you use AWS-LC in the first place? The de-facto standard TLS library on Linux is OpenSSL; AWS-LC is just some corporate fork of OpenSSL. Do I understand correctly that @pejobo didn’t realise that, when building with native TLS (which is optional, isn’t it?), he needs to install the native libraries (libssl-dev), and that you are using this as a reason to stop supporting native TLS? Or what is this about? > Because it's opinionated hour, I've also moved from native to webpki certificates on all platforms in https://github.com/librespot-org/librespot/commit/056d125cb2633efd9025188a70ecd1e38da8c1ad. Do you know what this means?! You are **bundling all the root certificates** with your binary! Do you understand all the implications of this? And why do you even want to do that? Now I have to patch librespot in all packages that use this library, which is complicated by the rigidity of Cargo. So I would rather remove them from the distribution because I’m really fed up with this approach of Rust community.

kerem commented

2026-02-27 19:32:01 +03:00

Author

Owner

@roderickvd commented on GitHub (Aug 14, 2025):

I acknowledge your technical concerns about certificate bundling, and you're right that this deserves better documentation instead of assuming everybody knows what's going on. So let me address both the technical reality and the tone of this discussion.

On this repository, we maintain a collaborative and constructive environment. This is the second time your responses have carried a confrontational tone, including threats to remove packages from distributions. We need future discussions to focus on technical solutions rather than ultimatums.

Regarding the certificate bundling concern: those certificates were already being bundled as transitive dependencies through hyper-proxy2 even when native TLS was enabled and default features disabled. Through the interaction of reqwest default features and this dependency, TLS silently used webpki certificates instead of system certificates, giving users false confidence about their certificate source.

The issue is that when cross-compilation was "succeeding" before, it was succeeding incorrectly. The build would complete without OpenSSL libraries because the dependency chain was silently using webpki certificates - meaning you were already shipping with bundled certificates without realizing it.

My recent commits make explicit what was happening implicitly through the dependency chain. Rather than shipping functionality that appears to use system certificates but actually uses bundled ones, we now have an honest implementation.

You're absolutely right that this solution isn't ideal, but the alternative was giving users false confidence about which certificate store they were actually using. This needs improvement in the Rust ecosystem, but that's not a problem we can solve today in librespot.

As referenced in #1158, we remain open to proper, full, cross-platform compatible native TLS solutions. Rather than arguing over the current approach, I encourage contributing to that effort.

@roderickvd commented on GitHub (Aug 14, 2025): I acknowledge your technical concerns about certificate bundling, and you're right that this deserves better documentation instead of assuming everybody knows what's going on. So let me address both the technical reality and the tone of this discussion. On this repository, we maintain a collaborative and constructive environment. This is the [second time](https://github.com/librespot-org/librespot/issues/1382#issuecomment-2836058204) your responses have carried a confrontational tone, including threats to remove packages from distributions. We need future discussions to focus on technical solutions rather than ultimatums. Regarding the certificate bundling concern: **those certificates were already being bundled as transitive dependencies through `hyper-proxy2` even when native TLS was enabled and default features disabled.** Through the interaction of `reqwest` default features and this dependency, TLS silently used webpki certificates instead of system certificates, giving users false confidence about their certificate source. The issue is that when cross-compilation was "succeeding" before, **it was succeeding incorrectly.** The build would complete without OpenSSL libraries because the dependency chain was silently using webpki certificates - **meaning you were already shipping with bundled certificates without realizing it.** My recent commits make explicit what was happening implicitly through the dependency chain. Rather than shipping functionality that appears to use system certificates but actually uses bundled ones, we now have an honest implementation. You're absolutely right that this solution isn't ideal, but the alternative was giving users false confidence about which certificate store they were actually using. This needs improvement in the Rust ecosystem, but that's not a problem we can solve today in librespot. As referenced in #1158, we remain open to proper, full, cross-platform compatible native TLS solutions. Rather than arguing over the current approach, I encourage contributing to that effort.

Rows
Columns

[GH-ISSUE #1534] Cross compilation fails because of missing system library openssl #695

Description

Version

How to reproduce

Log

[GH-ISSUE #1534] Cross compilation fails because of missing system library `openssl` #695