Skip to content

Conversation

@thesummer
Copy link
Contributor

Follow-up of #150484.
This PR updates libc to include the latest patches to make rtems target (and probably others) compile again.

@rustbot
Copy link
Collaborator

rustbot commented Jan 7, 2026

These commits modify the library/Cargo.lock file. Unintentional changes to library/Cargo.lock can be introduced when switching branches and rebasing PRs.

If this was unintentional then you should revert the changes before this PR is merged.
Otherwise, you can ignore this comment.

@rustbot rustbot added S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. T-libs Relevant to the library team, which will review and decide on the PR/issue. labels Jan 7, 2026
@rustbot
Copy link
Collaborator

rustbot commented Jan 7, 2026

r? @tgross35

rustbot has assigned @tgross35.
They will have a look at your PR within the next two weeks and either review your PR or reassign to another reviewer.

Use r? to explicitly pick a reviewer

@tgross35
Copy link
Contributor

tgross35 commented Jan 7, 2026

Mind waiting until tomorrow? I should have 0.2.180 out by then, which will include a handful of fixes on smaller targets (unbreaking uclibc)

@thesummer
Copy link
Contributor Author

Sure, no problem. Should I close this PR or just update it when the release is there?

@tgross35
Copy link
Contributor

tgross35 commented Jan 7, 2026

You can leave it open, I'll ping once the release is out

@thesummer thesummer changed the title Update libc to v0.2.179 Update libc to v0.2.180 Jan 8, 2026
@thesummer thesummer force-pushed the update-libc-0.2.179 branch from f581a0d to a45ec88 Compare January 8, 2026 12:31
@rustbot
Copy link
Collaborator

rustbot commented Jan 8, 2026

This PR was rebased onto a different main commit. Here's a range-diff highlighting what actually changed.

Rebasing is a normal part of keeping PRs up to date, so no action is needed—this note is just to help reviewers.

@tgross35
Copy link
Contributor

tgross35 commented Jan 8, 2026

Wow you're on top of things, I was just about to ping here

@thesummer
Copy link
Contributor Author

Just got an Email from the rustbot regarding the new libc release and updated the PR.


[target.'cfg(not(all(windows, target_env = "msvc")))'.dependencies]
libc = { version = "0.2.178", default-features = false, features = [
libc = { version = "0.2.179", default-features = false, features = [
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This isn't actually using the very latest (0.2.180)

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

yes, I did some errors locally with the git commands. Should be correct now.

@thesummer thesummer force-pushed the update-libc-0.2.179 branch from a45ec88 to 47c5f58 Compare January 8, 2026 12:36
Copy link
Contributor

@tgross35 tgross35 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks! LGTM once CI passes

View changes since this review

@tgross35
Copy link
Contributor

tgross35 commented Jan 8, 2026

@bors r+

@rust-bors rust-bors bot added S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Jan 8, 2026
@rust-bors
Copy link
Contributor

rust-bors bot commented Jan 8, 2026

📌 Commit 47c5f58 has been approved by tgross35

It is now in the queue for this repository.

matthiaskrgr added a commit to matthiaskrgr/rust that referenced this pull request Jan 8, 2026
Update libc to v0.2.180

Follow-up of rust-lang#150484.
This PR updates libc to include the latest patches to make rtems target (and probably others) compile again.
rust-bors bot added a commit that referenced this pull request Jan 8, 2026
Rollup of 12 pull requests

Successful merges:

 - #149961 (tidy: add if-installed prefix condition to extra checks system)
 - #150475 (std: sys: fs: uefi: Implement initial File)
 - #150533 (std: sys: fs: uefi: Implement remove_dir_all)
 - #150549 (fix missing_panics_doc in `std::os::fd::owned`)
 - #150699 (MGCA: Support literals as direct const arguments)
 - #150721 (Deprecated doc intra link)
 - #150752 (Update libc to v0.2.180)
 - #150802 (Minor cleanups to fn_abi_new_uncached)
 - #150803 (compiler-builtins subtree update)
 - #150809 (Update `literal-escaper` version to `0.0.7`)
 - #150811 (Store defids instead of symbol names in the aliases list)
 - #150825 (Query associated_item_def_ids when needed)

r? @ghost
matthiaskrgr added a commit to matthiaskrgr/rust that referenced this pull request Jan 8, 2026
Update libc to v0.2.180

Follow-up of rust-lang#150484.
This PR updates libc to include the latest patches to make rtems target (and probably others) compile again.
@matthiaskrgr
Copy link
Member

@bors try jobs=dist-ohos-x86_64

@rust-bors

This comment has been minimized.

rust-bors bot added a commit that referenced this pull request Jan 8, 2026
Update libc to v0.2.180

try-job: dist-ohos-x86_64
matthiaskrgr added a commit to matthiaskrgr/rust that referenced this pull request Jan 8, 2026
Update libc to v0.2.180

Follow-up of rust-lang#150484.
This PR updates libc to include the latest patches to make rtems target (and probably others) compile again.
@rust-bors rust-bors bot added the S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. label Jan 8, 2026
@rust-bors
Copy link
Contributor

rust-bors bot commented Jan 8, 2026

💔 Test for 607b25b failed: CI. Failed jobs:

@rust-log-analyzer
Copy link
Collaborator

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

Click to see the possible cause of the failure (guessed by this bot)
   Compiling addr2line v0.25.1
[RUSTC-TIMING] addr2line test:false 0.595
[RUSTC-TIMING] gimli test:false 4.544
[RUSTC-TIMING] object test:false 5.434
error[E0609]: no field `st_atime` on type `&libc::stat`
   --> /rustc/607b25bf27810d534722608988de8fcb5b8adfec/library/std/src/os/linux/fs.rs:370:30
    |
370 |         file_attr.as_inner().st_atime as i64
    |                              ^^^^^^^^ unknown field
    |
help: a field with a similar name exists
    |
370 -         file_attr.as_inner().st_atime as i64
370 +         file_attr.as_inner().st_atim as i64
    |

error[E0609]: no field `st_atime_nsec` on type `&libc::stat`
   --> /rustc/607b25bf27810d534722608988de8fcb5b8adfec/library/std/src/os/linux/fs.rs:373:36
    |
373 |         self.as_inner().as_inner().st_atime_nsec as i64
    |                                    ^^^^^^^^^^^^^ unknown field
    |
    = note: available fields are: `st_dev`, `st_ino`, `st_nlink`, `st_mode`, `st_uid` ... and 8 others

error[E0609]: no field `st_mtime` on type `&libc::stat`
   --> /rustc/607b25bf27810d534722608988de8fcb5b8adfec/library/std/src/os/linux/fs.rs:381:30
    |
381 |         file_attr.as_inner().st_mtime as i64
    |                              ^^^^^^^^ unknown field
    |
help: a field with a similar name exists
    |
381 -         file_attr.as_inner().st_mtime as i64
381 +         file_attr.as_inner().st_mtim as i64
    |

error[E0609]: no field `st_mtime_nsec` on type `&libc::stat`
   --> /rustc/607b25bf27810d534722608988de8fcb5b8adfec/library/std/src/os/linux/fs.rs:384:36
    |
384 |         self.as_inner().as_inner().st_mtime_nsec as i64
    |                                    ^^^^^^^^^^^^^ unknown field
    |
    = note: available fields are: `st_dev`, `st_ino`, `st_nlink`, `st_mode`, `st_uid` ... and 8 others

error[E0609]: no field `st_ctime` on type `&libc::stat`
   --> /rustc/607b25bf27810d534722608988de8fcb5b8adfec/library/std/src/os/linux/fs.rs:392:30
    |
392 |         file_attr.as_inner().st_ctime as i64
    |                              ^^^^^^^^ unknown field
    |
help: a field with a similar name exists
    |
392 -         file_attr.as_inner().st_ctime as i64
392 +         file_attr.as_inner().st_ctim as i64
    |

error[E0609]: no field `st_ctime_nsec` on type `&libc::stat`
   --> /rustc/607b25bf27810d534722608988de8fcb5b8adfec/library/std/src/os/linux/fs.rs:395:36
    |
395 |         self.as_inner().as_inner().st_ctime_nsec as i64
    |                                    ^^^^^^^^^^^^^ unknown field
    |
    = note: available fields are: `st_dev`, `st_ino`, `st_nlink`, `st_mode`, `st_uid` ... and 8 others

error[E0609]: no field `st_mtime` on type `libc::stat`
   --> /rustc/607b25bf27810d534722608988de8fcb5b8adfec/library/std/src/sys/fs/unix.rs:633:35
    |
633 |         SystemTime::new(self.stat.st_mtime as i64, self.stat.st_mtime_nsec as i64)
    |                                   ^^^^^^^^ unknown field
    |
help: a field with a similar name exists
    |
633 -         SystemTime::new(self.stat.st_mtime as i64, self.stat.st_mtime_nsec as i64)
633 +         SystemTime::new(self.stat.st_mtim as i64, self.stat.st_mtime_nsec as i64)
    |

error[E0609]: no field `st_mtime_nsec` on type `libc::stat`
   --> /rustc/607b25bf27810d534722608988de8fcb5b8adfec/library/std/src/sys/fs/unix.rs:633:62
    |
633 |         SystemTime::new(self.stat.st_mtime as i64, self.stat.st_mtime_nsec as i64)
    |                                                              ^^^^^^^^^^^^^ unknown field
    |
    = note: available fields are: `st_dev`, `st_ino`, `st_nlink`, `st_mode`, `st_uid` ... and 8 others

error[E0609]: no field `st_atime` on type `libc::stat`
   --> /rustc/607b25bf27810d534722608988de8fcb5b8adfec/library/std/src/sys/fs/unix.rs:668:35
    |
668 |         SystemTime::new(self.stat.st_atime as i64, self.stat.st_atime_nsec as i64)
    |                                   ^^^^^^^^ unknown field
    |
help: a field with a similar name exists
    |
668 -         SystemTime::new(self.stat.st_atime as i64, self.stat.st_atime_nsec as i64)
668 +         SystemTime::new(self.stat.st_atim as i64, self.stat.st_atime_nsec as i64)
    |

error[E0609]: no field `st_atime_nsec` on type `libc::stat`
   --> /rustc/607b25bf27810d534722608988de8fcb5b8adfec/library/std/src/sys/fs/unix.rs:668:62
    |
668 |         SystemTime::new(self.stat.st_atime as i64, self.stat.st_atime_nsec as i64)
    |                                                              ^^^^^^^^^^^^^ unknown field
    |
    = note: available fields are: `st_dev`, `st_ino`, `st_nlink`, `st_mode`, `st_uid` ... and 8 others

For more information about this error, try `rustc --explain E0609`.
[RUSTC-TIMING] std test:false 3.385
error: could not compile `std` (lib) due to 10 previous errors
Bootstrap failed while executing `dist --host=x86_64-unknown-linux-ohos --target x86_64-unknown-linux-ohos`

matthiaskrgr added a commit to matthiaskrgr/rust that referenced this pull request Jan 8, 2026
Update libc to v0.2.180

Follow-up of rust-lang#150484.
This PR updates libc to include the latest patches to make rtems target (and probably others) compile again.
@matthiaskrgr
Copy link
Member

@bors r-

@rust-bors
Copy link
Contributor

rust-bors bot commented Jan 8, 2026

Commit 47c5f58 has been unapproved.

@rust-bors rust-bors bot removed the S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. label Jan 8, 2026
@pheki
Copy link
Contributor

pheki commented Jan 11, 2026

Hey, 2 things:

First, it seems like the RTEMS target is actually compiling (my bad for the confusion as I'm the one who originally stated that the ambiguous export was blocking compilation for the vita). As I explained in this comment, when compiling rustc directly the lint is denied, but when using build-std it "just" shows a future-compat warning. You can also check the build history and the back-compat warning on does-it-build by noratrieb.

Second, it seems like libc v0.2.179 broke ohos, I'm assuming due to rust-lang/libc#4463. Should we notify the ohos maintainers?

@thesummer
Copy link
Contributor Author

@pheki Thanks for the pointer of does it build. Amazing.

I am a bit out of my depth here regarding the ohos problems. @tgross35 is this something to fix in the libc or in the rustc repo?

@tgross35
Copy link
Contributor

Argh. It should probably be changed in libc, the fields need to get a cfg(target_env = “ohos”) since ohis sets the musl_v1_2_3 config. musl_v1_2_3 isn’t intended to enable breaking changes on its own, only the time config should allow that.

Bit of a mess unfortunately, given the “similar but not identical” relationship between musl and ohos, and the lack of ohos testing.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. T-libs Relevant to the library team, which will review and decide on the PR/issue.

Projects

None yet

Development

Successfully merging this pull request may close these issues.

6 participants