-
Notifications
You must be signed in to change notification settings - Fork 433
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Static build support (openssl + cross-compile) #2207
Comments
This can be resolved by adjusting the Lines 61 to 63 in cffc3fa
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 As long as something in a downstream project opts in to 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? |
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. |
Not personally no. It was just an observation when I was trying to identify why What I did find was their Despite addressing that concern, the I may try investigate that further to track down if the downstream failure encountered with
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 :) |
Thank you for spending the time on this, I appreciate that. |
Since Quinn 0.11 has been released with ring 0.17, I think the factors preventing static compilation have been resolved. |
Summary
Static build support appears to be a bit broken?
While troubleshooting a bug encountered from a downstream project, I discovered it was related to
hickory-dns
when enabling thednssec-ring
feature. During this I noticedhickory-dns
fails to succeed at producing a static build on a-gnu
build host (including when cross-compiling for a-musl
target).Reproduction
This is understandable for a glibc "static" build, but is still the same output when attempting to build for a musl target. This is only when
OPENSSL_DIR
was specified, so presumably the glibc symbols and related warnings above with the musl target are due to the build attempting to bundle/link the glibc openssl on the build host?With both
cargo build
andcargo zigbuild
(without theOPENSSL_DIR
ENV present), the build failure for a musl target is more obvious (note:cargo zigbuild
cannot perform-gnu
target static builds):Despite having the development packages required, and using the
OPENSSL_DIR
or other supported ENVs from theopenssl
crate documentation, these are not helpful to support cross-compiling tomusl
target. Possibly due to a long standing issue withpkg-config
that may be environment specific? 🤷♂️Reproduction environment (Docker)
If it's helpful, the above can be reproduced with docker and the following commands:
Both should be capable of building statically linked musl target.
Whereas on a musl build host to avoid cross-compiling it will be successful as it can use static libs:
Expected outcome
It should be possible to build statically, at least for cross-compiling to a musl target?
Details
System:
Version:
Crate: hickory-util
Version: v0.24.1
The text was updated successfully, but these errors were encountered: