Static build support (openssl + cross-compile) about hickory-dns HOT 6 OPEN

Do you need Openssl?

Not personally no. It was just an observation when I was trying to identify why cargo-binstall was failing to resolve DNS while other programs had no issue. During that troubleshooting I tried both openssl and rustls but it didn't seem specific to either AFAIK.

What I did find was their trust-dns / hickory-dns feature (old project name is a feature alias) was the culprit. Specifically when the hickory-dns/dnssec-ring feature is enabled. As reported above, when I tried building this crate with that feature as a static build and with openssl (default) this failed. I looked into it and the only way for static build with openssl to work reliably across environments seems to require vendored to build from source, especially for cross-compilation to other targets.

Despite addressing that concern, the resolve utility was still working successfully like a dynamic linked build. I'm not sure what is different between that CLI and the cargo-binstall project, perhaps I wasn't actually using the feature via the resolve CLI just by enabling it at build 😓

I may try investigate that further to track down if the downstream failure encountered with cargo-binstall is reproducible with resolve CLI and then if that's specific to the ring crate, but I'm not sure if I'll have the time with my inexperience across these crates.

We've been trying to direct people to use the ring and rustls defaults.

Perhaps consider switching to those as the defaults in the future? If you do not think this concern with openssl and static build support is worth addressing, no worries, I just wanted to report my findings for others to benefit 👍

Feel free to close this issue if you like :)

from hickory-dns.

Thank you for spending the time on this, I appreciate that.

from hickory-dns.

This can be resolved by adjusting the openssl dep to use the vendored feature, which will build OpenSSL from source:

openssl = { version = "0.10.55", features = ["vendored"] }

The above reproduction environments in all three containers can then successfully build the project.

It is then possible to opt-out via OPENSSL_NO_VENDOR=1. AFAIK, there doesn't appear to be support for opt-in via ENV, hence I don't think there is no nice workaround available? (should be possible via editing a downstream project's Cargo.toml to override this deps openssl features.. but that seems a little brittle?)

As long as something in a downstream project opts in to vendored feature elsewhere, it also seems to have the same effect of building vendored, so it's not a feature you can control with explicit opt-out on a crate I think? Only at build time via the mentioned opt-out ENV?

I assume a potential drawback/side-effect for non-static builds is that vendoring in your own build of openssl into the binary instead of dynamically linking to openssl?

from hickory-dns.

Sounds like this is specific to openssl. Do you need Openssl? We've been trying to direct people to use the ring and rustls defaults.

from hickory-dns.

Since Quinn 0.11 has been released with ring 0.17, I think the factors preventing static compilation have been resolved.

from hickory-dns.

Well, only after #2107 (or something like it) has been merged (see also #2206).

from hickory-dns.