-
Notifications
You must be signed in to change notification settings - Fork 148
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
Add LIBSSH2_SYS_USE_PKG_CONFIG env var #88
Conversation
The latest actual release of libssh2 is old and broken. This uses the submodule instead unless you set `LIBSSH2_SYS_USE_PKG_CONFIG`. The mechanism is copied from libgit2.
I think this is for #87, right? If so, can you also add a comment or a note here as to why the latest release is broken? I forget at this point :( |
It was this issue. The latest release (1.8.0) isn't actually as old as I thought, though their releases do seem to be fairly infrequent so we might be waiting a while for another release. Even when they do do another release with that fix, I think it is good to have an option to use the vendored code, otherwise it's hard to make dependency-free binaries. Also if you randomly compile against system libraries it is very difficult to get hermetic / reproducible builds. |
Hm is it know why the system library failed there? For example where the segfault was coming from? |
No idea. Here is where it fails for me:
Which seems to be this code, but I have no idea why that would fail and it hasn't been changed recently. And I can't work out what the hell that |
Can you tell at runtime if there's perhaps two OpenSSL libraries loaded? Otherwise do you know what the faulting instruction is and can it perhaps be gleaned why it's the faulting instruction? |
Ah yeah that could be it:
Well that sucks. |
Hm ok that'd definitely cause problems! Mind leaving that in a comment (and maybe a link to this PR?)? After that should be good to merge! |
Thanks! |
In general can we please avoid these random magic environment variables? If the version is broken can you just detect it automatically? These random magic environment variables make things awkward for packagers, since it makes things not work out-of-the-box and we have to figure out which envvars to set to get things working again. |
I mean, by detecting the actual thing that is broken, rather than a version number, because we can and do patch things in Debian to fix broken versions. |
For context: in Debian we are forced to patch out this PR, because it is easier than trying to set the environment variable in all crates that depend on this crate. Debian packaging for Rust crates are automatically generated, so there is no easy way to detect whether any (direct or indirect) dependency requires some magic environment variable in order to "just work" with system libs. So we cannot really set this environment variable in all the cases where it's needed, it's easier to just patch this out. |
Fair point. I wonder if cargo needs a general option to tell packages whether or not to use system dependencies where possible. I can see that in Debian you basically always want to depend on other packages, but if you're building a binary that you are distributing outside of a package manager you basically never want to use system libraries. Perhaps another solution for Debian would be to create a central script that all Rust packages run, then you can just add this environment variable to that script if you really do want it for all packages the use this create. The ability to make easy to distribute binaries without having to worry about system dependencies is one of the things people absolutely love about Go and I don't think Rust should give it up lightly. |
We do have a central script that all Rust packages run called dh-cargo but it's not very sustainable to have to update it every time some rust crate decides they need their own environment variable. If the Rust ecosystem as a whole could decide on one single environment variable to use for this purpose (e.g. |
Bug: alexcrichton/ssh2-rs#88 Forwarded: not-needed Last-Update: 2018-07-28 Gbp-Pq: Name 2003_force-use-system-libssh2.patch
Bug: alexcrichton/ssh2-rs#88 Forwarded: not-needed Last-Update: 2018-07-28 Gbp-Pq: Name 2003_force-use-system-libssh2.patch
Bug: alexcrichton/ssh2-rs#88 Forwarded: not-needed Last-Update: 2018-07-28 Gbp-Pq: Name 2003_force-use-system-libssh2.patch
The latest actual release of libssh2 is old and broken. This uses the submodule instead unless you set
LIBSSH2_SYS_USE_PKG_CONFIG
. The mechanism is copied from libgit2.I haven't tested this, because I don't know how to get cargo to build everything with these changes. :-/