Build cannot find libssl.so.3

[lithp]

Bug Description

sqlx fails to compile on my machine using the "runtime-tokio-native-tls" feature, despite the existence of the correct library.

I do not believe this is a duplicate of #473 because vendoring openssl does not fix the problem for me.

Minimal Reproduction

$ cargo new ssl-test && cd ssl-test
$ cargo add sqlx --features runtime-tokio-native-tls
$ cargo add openssl --features vendored  # failure occurs whether or not I do this
$ cargo build -vv
...
   Compiling sqlx v0.6.2
     Running `CARGO=/home/brian/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/bin/cargo CARGO_CRATE_NAME=sqlx CARGO_MANIFEST_DIR=/home/brian/.cargo/registry/src/github.heygears.com-1ecc6299db9ec823/sqlx-0.6.2 CARGO_PKG_AUTHORS='Ryan Leckey <leckey.ryan@gmail.com>:Austin Bonander <austin.bonander@gmail.com>:Chloe Ross <orangesnowfox@gmail.com>:Daniel Akhterov <akhterovd@gmail.com>' CARGO_PKG_DESCRIPTION='🧰 The Rust SQL Toolkit. An async, pure Rust SQL crate featuring compile-time checked queries without a DSL. Supports PostgreSQL, MySQL, and SQLite.' CARGO_PKG_HOMEPAGE='' CARGO_PKG_LICENSE='MIT OR Apache-2.0' CARGO_PKG_LICENSE_FILE='' CARGO_PKG_NAME=sqlx CARGO_PKG_REPOSITORY='https://github.com/launchbadge/sqlx' CARGO_PKG_RUST_VERSION='' CARGO_PKG_VERSION=0.6.2 CARGO_PKG_VERSION_MAJOR=0 CARGO_PKG_VERSION_MINOR=6 CARGO_PKG_VERSION_PATCH=2 CARGO_PKG_VERSION_PRE='' LD_LIBRARY_PATH='/home/brian/wc/ssl-test/target/debug/deps:/home/brian/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib:/home/brian/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib:/nix/store/z18zgvspmxi88ipmk3f3nicvasfq3199-zlib-1.2.12/lib' rustc --crate-name sqlx --edition=2021 /home/brian/.cargo/registry/src/github.heygears.com-1ecc6299db9ec823/sqlx-0.6.2/src/lib.rs --error-format=json --json=diagnostic-rendered-ansi,artifacts,future-incompat --crate-type lib --emit=dep-info,metadata,link -C embed-bitcode=no -C debuginfo=2 --cfg 'feature="_rt-tokio"' --cfg 'feature="default"' --cfg 'feature="macros"' --cfg 'feature="migrate"' --cfg 'feature="runtime-tokio-native-tls"' --cfg 'feature="sqlx-macros"' -C metadata=edaacac4fd28f50a -C extra-filename=-edaacac4fd28f50a --out-dir /home/brian/wc/ssl-test/target/debug/deps -L dependency=/home/brian/wc/ssl-test/target/debug/deps --extern sqlx_core=/home/brian/wc/ssl-test/target/debug/deps/libsqlx_core-b2f14aa7e487b885.rmeta --extern sqlx_macros=/home/brian/wc/ssl-test/target/debug/deps/libsqlx_macros-668f3e99a9a67f70.so --cap-lints warn -L native=/home/brian/wc/ssl-test/target/debug/build/openssl-sys-f07918377ca000c4/out/openssl-build/install/lib`
error: libssl.so.3: cannot open shared object file: No such file or directory
  --> /home/brian/.cargo/registry/src/github.heygears.com-1ecc6299db9ec823/sqlx-0.6.2/src/lib.rs:67:1
   |
67 | pub extern crate sqlx_macros;
   | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

This debug output contains a few confusing tidbits:

• -L native=/home/brian/wc/ssl-test/target/debug/build/openssl-sys-f07918377ca000c4/out/openssl-build/install/lib

  Rustc appears to be given a static library to link against, and has no need to look for a dynamic library:

  $ ls /home/brian/wc/ssl-test/target/debug/build/openssl-sys-f07918377ca000c4/out/openssl-build/install/lib
   libcrypto.a  libssl.a  pkgconfig
  

• --extern sqlx_macros=/home/brian/wc/ssl-test/target/debug/deps/libsqlx_macros-668f3e99a9a67f70.so

  We had no problem finding the dynamic library when we built sqlx_macros:

  $ ldd /home/brian/wc/ssl-test/target/debug/deps/libsqlx_macros-668f3e99a9a67f70.so
   linux-vdso.so.1 (0x00007ffded787000)
   libssl.so.3 => /lib/x86_64-linux-gnu/libssl.so.3 (0x00007fcf6003f000)
   libcrypto.so.3 => /lib/x86_64-linux-gnu/libcrypto.so.3 (0x00007fcf5fbfd000)
   libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x00007fcf5fbdd000)
   libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007fcf5faf6000)
   libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007fcf5f8ce000)
   /lib64/ld-linux-x86-64.so.2 (0x00007fcf6047a000)
  

Info

• Operating system: Ubuntu 22.04, 5.15.0-56-generic x86_64
• rustc --version: rustc 1.65.0 (897e37553 2022-11-02)

Any help is appreciated, I'm in a bit over my head here.

[lithp]

I played with adding some tracing [1] and this appears to be happening because sqlx-macros links against libssl.so.3, but that library is not in the LD_LIBRARY_PATH which cargo passes to rustc, so rustc fails when it dlopens sqlx-macros [2].

I don't know how cargo or sqlx are meant to work so I'm not sure what is going wrong:

• for some reason LD_LIBRARY_PATH is not being populated correctly, cargo does not expect proc_macros to use dynamic libraries?
• sqlx-macros is being built incorrectly, and sqlx-macros should fail to build because the library it wants to link against, libssl.so.3, does not exist in LD_LIBRARY_PATH?

---

[1] RUSTC_LOG=trace RUSTFLAGS="-Z treat-err-as-bug" strace -v -s 128 -f -tt cargo build -vv >strace.log 2>&1

[2] rustc logs INFO rustc_metadata::creader register crate `sqlx_macros` , then opens and mmaps libsqlx_macros-5fe3159629220c74.so then looks for libssl.so.3 in each of the directories in LD_LIBRARY_PATH, and immediately returns an error after failing to find it in any of those directories. This is exactly what you would expect to see in this code path.

[Bauxitedev]

I fixed this by forcing sqlx to use rustls instead of OpenSSL in my Cargo.toml:

[workspace.dependencies.sqlx]
default-features = false
features = [
  "runtime-tokio-rustls",
  "macros",
  "postgres",
  "uuid",
  "chrono",
  "migrate",
]
version = "0.7.1"

You'll probably get the same error when trying to install sqlx-cli so install it like this:

cargo install sqlx-cli --no-default-features --features rustls,postgres

(assuming postgres database, replace it with another database if needed)

[Grafcube]

I was able to get around this issue by adding LD_LIBRARY_PATH = with pkgs; lib.makeLibraryPath [ openssl ]; to my nix flake. Since this doesn't just happen on NixOS, this must be some issue related to linking the package. Unfortunately I don't know enough to understand the problem any further.

I also want to note that before I started using a nix flake for my project very recently, I was building on Arch Linux with system packages and never ran into any issues (and still don't). Nix definitely puts the library in a different path but I'm not sure what Ubuntu does.