openssl dependency conflics breaks build

[letharion]

My local build fails with:

native library openssl is being linked to by more than one package, and can only be linked to by one package
openssl-sys v0.7.0
openssl-sys v0.6.7

Hacking the library to depend on 0.6.7 fixes the build, for now at least.

[illegalprime]

Are you building off master or from crates.io or a specific commit?
Also what architecture are you building on?

[letharion]

Using cargo, so building from crates.io.
I tried with 0.13.1 and 0.12.2. (Might also have tried *)
Ubuntu 15.10, x86_64.

[baevold]

Same distro and same error here.
However, a small gotcha. I had a local copy of my repo. This compiled just fine until I did 'cargo clean'. Maybe cargo caches version info somehow.

According to cargo.lock file:
websocket 0.13.1 depends on hyper 0.6.16 and openssl 0.7.0
hyper 0.6.16 depends on openssl 0.6.7

For reference:
rustc 1.4.0 (8ab8581f6 2015-10-27)
cargo 0.5.0-nightly (833b947 2015-09-13)

[dten]

also had the same
I fixed it by saying websocket needs ^0.6.4
https://github.com/dten/rust-websocket/commit/64200c928630d36a09478af1e98028c529e1d7bc

dunno if you want to do that though..

[illegalprime]

Yeah this lib has needed to lock down its versions for a while, although I would rather try to target the most recent version. Haven't had a chance to look into this issue deeply just yet.

[alkis]

This is because hyper depends on openssl 0.6.4 and websocket on 0.7.0. Either hyper needs to depend on 0.7.0 or websocket on 0.6.4.

[cyderize]

Yeah, until hyper is updated to use 0.7.0, our only choice really is to use 0.6.4.

[alkis]

The original comment says it works with 0.6.7 as well. Is it possible to pick whichever one works and push a new release to crates.io?

[letharion]

I messed around a bit with hyper, and it needs to upgrade it's version of "cookie" as cookie has the same dependency. Unfortunately some cookie related tests fail if I try that locally, so it's not entirely trivial to bump the openssl version.

[letharion]

I suppose that one possible (though not ideal?) would be to drop the dependency on websocket, since it would be pulled in by hyper anyway. That would "automatically" made the libs sync. It's worth noting that the openssl dep is optional though for hyper.

[cyderize]

I believe this is now fixed, although I'm still wondering if there's a better way to avoid the version conflict. I'm quite tempted to try to actually remove hyper from the library and use httparse only, but that'd probably be quite difficult to do.

[illegalprime]

@cyderize I am already in the midst of doing this on my fork (although using http-muncher) but I had to stop working on it recently because of time constraints. What do you think on http-muncher vs. httparse ?

[cyderize]

@illegalprime I'm not sure which would be more suitable (my suspicion is that it probably doesn't really matter). I was thinking of httparse because it's already stable (1.0.0) and it's what's used in hyper, so I kind of already knew about it. I'll look into http-muncher some more - it seems interesting