can't reproduce release build of 0.2.0 (EDIT: on 32-bit arm) about gps-share HOT 9 CLOSED

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

from gps-share.

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.

from gps-share.

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.

from gps-share.

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.

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 out

from gps-share.

BUT 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`

from gps-share.

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.

from gps-share.

also since I don't have a armv7 build machine around, it'd be awesome if you could submit a PR.

from gps-share.

Well, I am not happy. Here is some reasearch I did:

The first error refers to argument 3 of the C getnameinfo function.

Here is the C declaration of that function on x86_64, Debian 10, GNU libc 2.28 (matching dockerhub rust:1.42.0-buster):

/* 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);

Here is the C declaration of that function on armv7-a, Debian 10, GNU libc 2.28 (matching dockerhub arm32v7/rust:1.42.0-buster):

/* 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 ... :/

from gps-share.

@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 :(

from gps-share.