INTRODUCTION ============ Some people want to suffer so they use LibreSSL system-wide. "openssl" crate is very paranoid about libressl's API/ABI stability (not without reasons tbh), so only explicitly listed versions are supported. The problem is, Rust dependencies are pinned and often lag behind several releases. It's really hard for downstream to replace a crate with a newer one. SOLUTION ======== cargo-c has optional support for vendored openssl (can be enabled with "--features vendored-openssl"). cargo.eclass uses "myfeatures" local array and "cargo_src_configure" for that (unfortunately, the ebuild doesn't call it). I confirm that cargo-c builds and runs when vendored openssl is used.
Honestly that sounds like something which a libressl overlay should be doing. And then it could set it unconditionally, if it wants to. Is there any circumstance where someone using gentoo's official openssl support would want to have cargo-c vendor it?
(In reply to Eli Schwartz from comment #1) > Honestly that sounds like something which a libressl overlay should be > doing. And then it could set it unconditionally, if it wants to. The libressl overlay also been patching this crate to let it work with libressl (e.g. [1]), and I'd imagine most libressl users would prefer that to using a shoved-under-the rug vendored openssl. > Is there any circumstance where someone using gentoo's official openssl > support would want to have cargo-c vendor it? Can't think of any, and ::gentoo stance is that it won't take workarounds for libressl anymore. We just don't support it. [1] https://github.com/gentoo/libressl/blob/master/dev-python/cryptography/files/cryptography-41.0.3-libressl-openssl-sys.patch
> Can't think of any, and ::gentoo stance is that it won't take workarounds > for libressl anymore. We just don't support it. That's the official policy. But also: https://bugs.gentoo.org/903001#c16
May I ask you to add proper "cargo_src_configure" call at the end of "src_configure"? That would leave me satisfied.
