Closed Josua-SR closed 4 years ago
zeenix
commented
4 years ago Thanks for reporting with all the detail! From the first look it seems I used some unstable API (i wrote this code years ago) and now it changed. Should be trivial to fix, as you can see from the error. Care to send a PR? If not, I'll look into it soon.
Josua-SR
commented
4 years ago I have attempted a fix that purely follows the error message:
diff --git a/src/config.rs b/src/config.rs
index f04af20..993508e 100644
--- a/src/config.rs
+++ b/src/config.rs
@@ -94,7 +94,7 @@ impl Config {
libc::AF_INET6 => size = mem::size_of::<libc::sockaddr_in6>() as u32,
_ => continue,
};
- let host_ptr = host.into_raw() as *mut i8;
+ let host_ptr = host.into_raw() as *mut u8;
let ret = libc::getnameinfo(
addr.ifa_addr,
size,
This is enough for the build to succeed with 0.42.0. No runtime testing done so far though, and I don't know rust, so .... ..... ....... you shpould be the judge if this is the right fix
zeenix
commented
4 years ago This is enough for the build to succeed with 0.42.0. No runtime testing done so far though, and I don't know rust, so .... ..... ....... you shpould be the judge if this is the right fix
Awesome. For testing, just see if cargo test succeeds.
Josua-SR
commented
4 years ago This is enough for the build to succeed with 0.42.0. No runtime testing done so far though, and I don't know rust, so .... ..... ....... you shpould be the judge if this is the right fix
Awesome. For testing, just see if
cargo testsucceeds.
Thanks for the quick replies!
cargo test does indeed succeed. The only thing that surprised me is that it triggered a rebuild after I had already done cargo build --release in a previous step.
Running target/debug/deps/stdin_gps-9c1b383e1c89bdd0
running 3 tests
test test_stdin_gps_with_port ... ok
test test_stdin_gps_with_port_iface ... ok
test test_stdin_gps_defaults ... ok
test result: ok. 3 passed; 0 failed; 0 ignored; 0 measured; 0 filtered outBUT BEWARE ... I was building on armv7-a!
Turns out that the signage is different for x86_64 ....
error[E0308]: mismatched types
--> src/config.rs:101:17
|
101 | host_ptr,
| ^^^^^^^^ expected `i8`, found `u8`
|
= note: expected raw pointer `*mut i8`
found raw pointer `*mut u8`BUT BEWARE ... I was building on armv7-a!
Ah, that explains it then. :) You can check for architecture and use the correct signage. If you make it a PR, the CI will run the tests on x86-64 so you won't need to worry about the diff.
zeenix
commented
4 years ago also since I don't have a armv7 build machine around, it'd be awesome if you could submit a PR.
Josua-SR
commented
4 years ago Well, I am not happy. Here is some reasearch I did:
The first error refers to argument 3 of the C getnameinfo function.
/* Translate a socket address to a location and service name.
This function is a possible cancellation point and therefore not
marked with __THROW. */
extern int getnameinfo (const struct sockaddr *__restrict __sa,
socklen_t __salen, char *__restrict __host,
socklen_t __hostlen, char *__restrict __serv,
socklen_t __servlen, int __flags);/* Translate a socket address to a location and service name.
This function is a possible cancellation point and therefore not
marked with __THROW. */
extern int getnameinfo (const struct sockaddr *__restrict __sa,
socklen_t __salen, char *__restrict __host,
socklen_t __hostlen, char *__restrict __serv,
socklen_t __servlen, int __flags);On both architectures the GNU libc defines the third argument as a pointer to signed char. So imo the correct version is signed, always ... :/
Josua-SR
commented
4 years ago @zeenix Can you use the c_char type from the rust libc bindings?
See https://github.com/rust-lang/libc/blob/master/src/unix/linux_like/linux/mod.rs#L2862 - it is used for declaration of the function to rust. I believe that would be the best solution. Why the rust libc bindings have a different signage where gnu does not is beyond me though :(
Building gps-share fails with:
All builds were performed using debian based rust toolchain available on dockerhub, namely
rust:1.28.0-stretchrust:1.31.1-stretchrust:1.42.0-busterSample Dockerfile:
So in chronological order:
1.28.0
^^ Well, apparently this cargo (1.28.0) is too old
1.31.1
^^ Hmph.
1.42.0
Now that's a lot of noise, but the error is same as with 1.31.1 .... any ideas?