Fails to compile - error[E0599]: no method named `si_status` found for struct `siginfo_t` about process_control HOT 6 CLOSED

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.

from process_control.

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.

from process_control.

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

from process_control.

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...

from process_control.

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?

from process_control.

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! 💯

from process_control.