linux(uclibc): remove redundant records and explicit linking to libutil

[dybucc]

Description

This PR consists of a small clean up over the linux/uclibc module. It removes
some records that were already declared in top-level modules. It also removes an
explicit linking directive to libutil as part of ongoing efforts in #5265.

Sources

None. The records that were removed were already declared in top-level modules,
but the combination of target architecture, OS and libc implementation does not
currently exist as an officially supported Rust target.

Checklist

• Relevant tests in libc-test/semver have been updated
• Commit messages permalink to headers for added or changed API
• Placeholder or unstable values like *LAST or *MAX have the standard
  doc comment
• Tested locally (cargo test -p libc-test --target mytarget); especially
  relevant for platforms that may not be checked in CI

[tgross35]

It would be ideal if this could be gated behind a cfg, similar to what we have on musl and glibc, to give users a chance to test things out prior to 1.0. Same for any other platforms that haven't had this done yet. I'm less concerned about it for tier 3 targets but would have some reservations about merging this or other PRs that only target main until we're closer to 1.0, given how conflict-prone it tends to make any backports.

There's one record I'm particularily doubtful of. In libc we choose to expose ever so slightly different definition for the statvfs structure depending on the target's endianness. This only affects whether a field appears before or after some padding, the latter of which depends on the target's word size. Other modules under the uclibc module do not seem to use this endian-dependent field ordering, so that has been removed as there's neither any indication in the upstream definition of there being need for that. Still, this is very much a change prone to reversion, if I'm, indeed, missing something. Input here is very much welcome.

That very well could have been a copy+paste error, I very much doubt anybody is using these structs on uclibc today to the point that these kind of bugs would show up.

[tgross35]

The author of #5046 indicated that uclibc has a preference for keeping the small sizes, so I think this will need to remain configurable even post-1.0.

Cc @skrap for your thoughts here.

[dybucc]

Just read through that PR and the comments. I'm not quite sure I understand why that is the case. Hopefully the maintainer can clear things up (not pinging again.)

I've already updated the PR with support for the cfg. The option ensures the unsuffixed types are exposed for targets with a 32-bit machine word size, as otherwise suffixed and unsuffixed types are equivalent.

A bunch of the suffixed type definitions were removed from the uclibc module in favor of the top-level unix, unix/linux_like and unix/linux_like/linux modules. Those already provide the base types for most file offset types. The rest have been left in the linux/uclibc module.

[dybucc]

The CI label is wrong. At one point, I changed files concerning CI but I then realized all targets using uClibc are tier 3, and the only included target in verify_build.py uses L4Re and not Linux.

[rustbot]

Error: Label A-CI can only be set by Rust team members

Please file an issue on GitHub at triagebot if there's a problem with this bot, or reach out on #triagebot on Zulip.

[skrap]

Do these changes necessitate a minimum version of uclibc in order to pass the libc tests? I see that the checkbox indicating the libc-test has not been marked complete. Please make sure you do so, because there's often some subtle bugs which the tests catch!

As for the 32- vs 64-bit file lengths, it's my experience that the length of this field varies between uclibc configurations. Is that understanding not up to date?

[tgross35]

There seem to be some struct fixes and cleanups that aren't related to uclibc_file_offset_bits64 changes. Can anything that is either a correction or a non-functional cleanup be split to a PR? Those don't need to be involved in LFS64 alias discussion, which seems more complicated on uclibc than other targets.

Not positive about what to do with the rest here if it's configurable on uclibc.

View changes since this review

[rustbot]

Reminder, once the PR becomes ready for a review, use @rustbot ready.

[dybucc]

Do these changes necessitate a minimum version of uclibc in order to pass the libc tests? I see that the checkbox indicating the libc-test has not been marked complete. Please make sure you do so, because there's often some subtle bugs which the tests catch!

As for the 32- vs 64-bit file lengths, it's my experience that the length of this field varies between uclibc configurations. Is that understanding not up to date?

About configurability:

• It's configurable. There's some things to note. 32-bit targets see a difference. They get 64-bit suffixed types. Their unsuffixed types remain 32-bits. 64-bit targets have no effective difference. Their unsuffixed types are equivalent to their suffixed types.
• Supporting unsuffixed types is unreasonable. 32-bit targets are the exception.

About versioning:

• I have not checked all versions. I have checked uclibc-ng. The earliest I checked was v1.0.0. The original uclibc does not have any of these. uclibc-ng has existed since 2017. It's fair to base changes off of uclibc-ng.

[dybucc]

There seem to be some struct fixes and cleanups that aren't related to uclibc_file_offset_bits64 changes. Can anything that is either a correction or a non-functional cleanup be split to a PR? Those don't need to be involved in LFS64 alias discussion, which seems more complicated on uclibc than other targets.

Not positive about what to do with the rest here if it's configurable on uclibc.

View changes since this review

32-bit targets are configurable. 64-bit targets also are. The suffixed and unsuffixed types are equivalent in 64-bit targets. There's no reason to support them. 32-bit targets are the exception.

[dybucc]

There seem to be some struct fixes and cleanups that aren't related to uclibc_file_offset_bits64 changes. Can anything that is either a correction or a non-functional cleanup be split to a PR? Those don't need to be involved in LFS64 alias discussion, which seems more complicated on uclibc than other targets.

Not positive about what to do with the rest here if it's configurable on uclibc.

View changes since this review

They can't be separated. They may seem tangential. They're actually necessary. An example is flock. It seems like I reorganized its definition across modules. But it also has some conditionally compiled fields. These use the cfg introduced in this PR.

Though changes have now been separated into separate commits.

@rustbot ready

[tgross35]

"linux(uclibc): remove explicit linking to libutil" seems reasonable to me, especially with #5265

View changes since the review

[tgross35]

"linux(uclibc): remove conflicting records": The message currently says:

Remove records that are already declared in top-level modules. This
affects x86_64 only. There is no such supported Rust target. This change
should virtually affect nobody.

Who does this affect at all? The definitions look identical

View changes since the review

[dybucc]

i didn't mean the changes to have an effect on end users. i meant that the changes were only to the x86_64 module. that's why i top it off by saying that it should virtually affect nobody.

[tgross35]

"linux(uclibc): add cfg for lfs64 bindings": this should check for a value (32 or 64)

View changes since the review

[dybucc]

done.

[tgross35]

They can't be separated. They may seem tangential. They're actually necessary. An example is flock. It seems like I reorganized its definition across modules. But it also has some conditionally compiled fields. These use the cfg introduced in this PR.

I don't believe this is accurate. The commit messages are "linux(uclibc): fix stat struct family defs" and "linux(uclibc): fix cross-architecture flock def" which implies something was broken prior to this PR, right?

The confusing bit is probably the dependency: those fix commits depend on "linux(uclibc): add cfg for lfs64 bindings" but they shouldn't. Instead, any fix commits should come first and do anything that is necessary to make things correct with the config we have today. Only after the current setup is fixed, "add cfg for lfs64" can introduce the cfg and use it (i.e. update stat et al) in the same patch, meaning that tests should pass on either side of that commit.

I realize that's annoying rebase work, so don't worry about it if the target maintainer is happy with the net changes as-is. Just noting that atomicity makes for history that's easier to understand.

[dybucc]

I don't believe this is accurate. The commit messages are "linux(uclibc): fix stat struct family defs" and "linux(uclibc): fix cross-architecture flock def" which implies something was broken prior to this PR, right?

the thing is that breakage is only made obvious when the corresponding feature test macro (i.e. FILE_OFFSET_BITS=64) is set. if some user has set it in the c standard library implementation they are linking with, but they are getting the fields in rust that would correspond with the macro not being set, things could get awkward when crossing ffi boundaries.

considering this is a fairly popular macro that we already provide a cfg for in glibc environments, i thought this was necessary.

the fix itself is in adding the cfg and conditionally defining some fields at compile-time. the only exception to this are some integer fields whose signedness was not quite right, and some padding fields that were not using our Padding util type. i just decided to package those up in the same commit.

[tgross35]

I don't believe this is accurate. The commit messages are "linux(uclibc): fix stat struct family defs" and "linux(uclibc): fix cross-architecture flock def" which implies something was broken prior to this PR, right?

the thing is that breakage is only made obvious when the corresponding feature test macro (i.e. FILE_OFFSET_BITS=64) is set. if some user has set it in the c standard library implementation they are linking with, but they are getting the fields in rust that would correspond with the macro not being set, things could get awkward when crossing ffi boundaries.

That's reasonably accurate, but it doesn't really fit a compatibility story. Every platform comes with dozens of build options that easily make anything not work, and it's not within libc's capabilities to represent all of them. If somebody builds their C library with options that we don't support, it's not libc that's broken - it's the build configuration.

If you would like to move this forward then I am happy to take the following patches as-is:

• "linux(uclibc): remove explicit linking to libutil"
• "linux(uclibc): remove conflicting records"

The rest unfortunately I have to nack because it combines the addition of a brand new option (the FILE_OFFSET_BITS config) with other fixes. If the target maintainer reviews and feels strongly then I'll take them anyway, but I'm having too hard of a time following what is needed to support a new configuration vs. what needs updating to correct our current configuration.

We may still want FILE_OFFSET_BITS, up to the target maintainer if that's useful or not. But I'd really recommend splitting it to a separate PR.

@rustbot author

[dybucc]

I've changed the PR now. I also opened #5315 with the patchset concerning the
new cfg.

I believe the patch that removed the redundant records can be made to remove the
whole linux/uclibc/x86_64 module. There's no officially supported Rust target
with that target triple combination.

@rustbot ready

[rustbot]

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.