Fails to compile - error[E0599]: no method named si_status found for struct siginfo_t

[vladimyr]

Hi, @dylni 👋

unfortunately, those boring Starship folks are back again to report some more issues 🙃

This time v3.0.1 failed to compile inside termux/package-builder docker image (https://github.com/termux/termux-packages/blob/master/scripts/Dockerfile) which is used for cross-compiling Termux packages:
https://github.com/termux/termux-packages/runs/1944936544

I believe the environment itself isn't problematic but the way how si_status gets retrieved. Maybe I'm reading this completely wrong and at risk of asking something totally stupid: is it accidentally invoked instead of just being accessed? 🤔
https://github.com/dylni/process_control/blob/3.0.1/src/unix.rs#L171

signal.h manpage says si_status should be declared as an int struct member:

The <signal.h> header shall define the siginfo_t type as a
structure, which shall include at least the following members:

 int           si_signo  Signal number.
 int           si_code   Signal code.
 int           si_errno  If non-zero, an errno value associated with
                         this signal, as described in <errno.h>.
 pid_t         si_pid    Sending process ID.
 uid_t         si_uid    Real user ID of sending process.
 void         *si_addr   Address of faulting instruction.
 int           si_status Exit value or signal.
 long          si_band   Band event for SIGPOLL.
 union sigval  si_value  Signal value.

and compilation ends with following error:

error[E0599]: no method named `si_status` found for struct `siginfo_t` in the current scope
   --> /home/builder/.cargo/registry/src/github.com-1ecc6299db9ec823/process_control-3.0.1/src/unix.rs:171:58
    |
171 | ...                   value: unsafe { process_info.si_status() },
    |                                                    ^^^^^^^^^ method not found in `siginfo_t`

Once again, thank you for all your patience and extensive help in dealing with BSDs, and thank you in advance for all the future help! 💯

[vladimyr]

Linking termux/termux-packages#6432 for visibility. 🔗

[vladimyr]

Maybe I'm reading this completely wrong and at risk of asking something totally stupid: is it accidentally invoked instead of just being accessed? thinking

Ok, I'm definitely asking a stupid question: https://docs.rs/libc/0.2.88/libc/struct.siginfo_t.html#method.si_status 🤦

Time for some more digging...

[vladimyr]

Ok, I got it. 🎉

Termux build used libc v0.2.82 and building with it results in the already known error:

u0_a202 in localhost in process_control on  master [!] is 📦 v3.0.1 via 🦀 v1.50.0 
❯ grep libc Cargo.toml
libc = "= 0.2.82"

u0_a202 in localhost in process_control on  master [!] is 📦 v3.0.1 via 🦀 v1.50.0 
❯ cargo test                
   Compiling process_control v3.0.1 (/data/data/com.termux/files/home/workspace/github.com/dylni/process_control)
error[E0599]: no method named `si_status` found for struct `siginfo_t` in the current scope
   --> src/unix.rs:171:58
    |
171 | ...                   value: unsafe { process_info.si_status() },
    |                                                    ^^^^^^^^^ method not found in `siginfo_t`

error[E0599]: no method named `si_status` found for struct `siginfo_t` in the current scope
   --> src/unix.rs:171:58
    |
171 | ...                   value: unsafe { process_info.si_status() },
    |                                                    ^^^^^^^^^ method not found in `siginfo_t`

error: aborting due to previous error

For more information about this error, try `rustc --explain E0599`.
error: aborting due to previous error

For more information about this error, try `rustc --explain E0599`.
error: could not compile `process_control`

To learn more, run the command again with --verbose.
warning: build failed, waiting for other jobs to finish...
error: build failed

OFC, after I removed the manual version override it used latest libc version (v0.2.88) and compiled successfully:

u0_a202 in localhost in process_control on  master is 📦 v3.0.1 via 🦀 v1.50.0 took 5s 
❯ cargo test >/dev/null 2>&1 && grep -A2 libc Cargo.lock
name = "libc"
version = "0.2.88"
source = "registry+https://github.com/rust-lang/crates.io-index"
--
 "libc",
 "winapi",
]

And if I actually went and check out libc source before lazily opening this issue I would certainly notice recent PR (released as part of v0.2.87) that explains everything: rust-lang/libc#2082

Finally, because it isn't process_control issue at all I'm closing this one but maybe it is still a good idea to bump the minimum libc version to v0.2.88?
@dylni What do you think?

[dylni]

Hi @vladimyr 👋 Sorry for the delayed response.

Ok, I'm definitely asking a stupid question

It's reasonable for you to assume it would be a field. The maintainers want it to be a field too. That it's not is surprising when you first look at the code.

And if I actually went and check out libc source before lazily opening this issue I would certainly notice recent PR (released as part of v0.2.87) that explains everything: rust-lang/libc#2082

Don't worry. It's great that you were able to find a quick resolution.

Finally, because it isn't process_control issue at all I'm closing this one but maybe it is still a good idea to bump the minimum libc version to v0.2.88?

I generally don't increase the minimum version for platform support, because a crate may need to rely on an older version for some reason. However, I will consider doing this once some time has passed. Is this something that would help you currently?

Once again, thank you for all your patience and extensive help in dealing with BSDs, and thank you in advance for all the future help! 💯

I'm happy to help. I prefer my projects to support as many systems as feasible.

[vladimyr]

Thank you for answering my questions/stream of thoughts 👍 🙃

I generally don't increase the minimum version for platform support, because a crate may need to rely on an older version for some reason. However, I will consider doing this once some time has passed. Is this something that would help you currently?

Actually on the Starship end issue has been fully resolved by locking libc to the latest version inside Cargo.lock so we are good. That was just my suggestion. I understand your reasoning and I believe we are on the same page, sounds like a plan! 👍

I'm happy to help. I prefer my projects to support as many systems as feasible.

People might be unaware of how tedious and challenging it can be sometimes so kudos for (keep) doing that! 💯

[dylni]

Thanks for the kind words. 😊

Actually on the Starship end issue has been fully resolved by locking libc to the latest version inside Cargo.lock so we are good.

Great to hear! Please reach out if you have any more trouble.