Update libc to 0.2.121

[glaubitz]

Updating libc to 0.2.119 adds platform support for m68k-unknown-linux-gnu.

[rust-highfive]

r? @Mark-Simulacrum

(rust-highfive has picked a reviewer for you, use r? to override)

[Mark-Simulacrum]

@bors r+ rollup

[bors]

📌 Commit cc9fecc has been approved by Mark-Simulacrum

[matthiaskrgr]

@bors r-
failed in a rollup: #94151 (comment)

[glaubitz]

@bors r- failed in a rollup: #94151 (comment)

Just rebased and repushed. Could you approve the PR again? Thanks!

[Mark-Simulacrum]

@bors r+

[bors]

📌 Commit d98a052 has been approved by Mark-Simulacrum

[matthiaskrgr]

Looks like there is still a problem: #94251 (comment)
@bors r- rollup=never

[glaubitz]

Looks like there is still a problem: #94251 (comment)@bors r- rollup=never

That looks more like a missing build dependency on the CI host.

The library packages libsendfile and liblgrp need to be installed.

[glaubitz]

Both libsendfile and liblgrp seem to be exclusive Solaris libraries. So, I'm not sure how to download them on the Ubuntu host for cross-compilation.

@psumbera Do you have any suggestion how to fix the CI build for Solaris x86_64?

[Dylan-DPC]

failed in rollup

@bors r-

[klensy]

failed in rollup

@bors r-

rollup=never ?

[MabezDev]

Could we try and merge this again?

[Dylan-DPC]

@bors r+

[bors]

📌 Commit e69e652 has been approved by Dylan-DPC

[bors]

⌛ Testing commit e69e652 with merge f1e86a7708a6670a98f2efb3d63a9759ef4b286c...

[bors]

💔 Test failed - checks-actions

[rust-log-analyzer]

The job dist-x86_64-illumos failed! Check out the build log: (web)(plain)

Click to see the possible cause of the failure (guessed by this bot)

[RUSTC-TIMING] addr2line test:false 0.399
[RUSTC-TIMING] core test:false 22.842
[RUSTC-TIMING] gimli test:false 4.364
[RUSTC-TIMING] object test:false 4.478
error[E0615]: attempted to take value of method `si_addr` on type `siginfo_t`
--> library/std/src/sys/unix/stack_overflow.rs:70:17
|
70 | (*info).si_addr as usize
|
help: use parentheses to call the method
|
|
70 | (*info).si_addr() as usize
For more information about this error, try `rustc --explain E0615`.
[RUSTC-TIMING] std test:false 2.225
error: could not compile `std` due to previous error

[glaubitz]

The job dist-x86_64-illumos failed! Check out the build log: (web) (plain)

I guess we should disable the Illumos CI for the time being. It makes no sense to block future libc updates because of a single, less common target. Unless someone knows how to fix this issue.

[pfmooney]

I guess we should disable the Illumos CI for the time being.

I'd like to help solve the issue to avoid that outcome, please.

As of 0.2.121, all of the UNIX-ish platforms in libc now have an si_addr() accessor. I've drafted pfmooney/rust@f9e8d05, which should hopefully solve the illumos issue, as well as consolidating the logic for the other platforms.

I haven't been able to build it yet, as I'm resurrecting my rust bootstrap build environment.

(edit: Updated reference to drafted fix)

[glaubitz]

I guess we should disable the Illumos CI for the time being.

I'd like to help solve the issue to avoid that outcome, please.

I'm not opposed to fixing the underlying problem, of course.

As of 0.2.121, all of the UNIX-ish platforms in libc now have an si_addr() accessor. I've drafted pfmooney/rust@f9e8d05, which should hopefully solve the illumos issue, as well as consolidating the logic for the other platforms.

Correct if I'm wrong but didn't Illumos use the si_addr() accessor before!?

I haven't been able to build it yet, as I'm resurrecting my rust bootstrap build environment.

Why not just create a PR with the libc update included and see if both changes together build?

[pfmooney]

Correct if I'm wrong but didn't Illumos use the si_addr() accessor before!?

It was using the si_addr public field, rather than the si_addr() accessor method. When exposing other parts of the siginfo_t on illumos, it was updated to expose si_addr(), which all of the other UNIX-y platforms had added. This also did away with the fiction of the si_addr field on illumos, since it's not a field on that struct, but rather a deeper member of siginfo data union.

Why not just create a PR with the libc update included and see if both changes together build?

I've since done that locally, building for both Linux and illumos as small test cases. I wasn't sure how you wanted to proceed with this PR, either including the aforementioned patch to use si_addr(), or respinning as a whole new PR. Please let me know what would be best.

[glaubitz]

Why not just create a PR with the libc update included and see if both changes together build?

I've since done that locally, building for both Linux and illumos as small test cases. I wasn't sure how you wanted to proceed with this PR, either including the aforementioned patch to use si_addr(), or respinning as a whole new PR. Please let me know what would be best.

Feel free to just pick my patch and create a new PR. Or just, if you already have done so, use your own patch to update libc.

I don't insist on this PR coming from myself ;). If we can get libc updated, I'm more than happy.

[pfmooney]

Feel free to just pick my patch and create a new PR. Or just, if you already have done so, use your own patch to update libc.

I don't insist on this PR coming from myself ;). If we can get libc updated, I'm more than happy.

Cool, thanks. I've opened #95688 with the combined changes.

[glaubitz]

I would have split it into two commits though.

[pfmooney]

I would have split it into two commits though.

Generally speaking, I agree.

In this case, the intermediate commits would fail to build by themselves, since the si_addr() accessor was added in the newer libc. It makes sense as a single unit, I think.

[glaubitz]

I would have split it into two commits though.

Generally speaking, I agree.

In this case, the intermediate commits would fail to build by themselves, since the si_addr() accessor was added in the newer libc. It makes sense as a single unit, I think.

Hmm, fair enough. Let's hope the CI succeeds so we can finally get this fixed.

[glaubitz]

@Mark-Simulacrum Can you approve #95688 instead? I'm closing this one.