Skip to content

6.1: Support for building with 64-bit time_t/off_t on 32-bit platforms #1388

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
wants to merge 2 commits into
base: release/6.1
Choose a base branch
from

Conversation

lhoward
Copy link

@lhoward lhoward commented Jun 28, 2025

  • Explanation: support for building with 64-bit time_t/off_t on 32-bit platforms
  • Scope: minimal, although care should be taken it does not regress on any non-Linux platforms that export a Glibc module such as FreeBSD
  • Issues:
  • Original PRs: Support for building with 64-bit time_t/off_t on 32-bit platforms #1395
  • Risk: build should be validated on all platforms
  • Testing: tested as part of Yocto build on armv7
  • Reviewers: pending

lhoward added 2 commits June 28, 2025 11:58
It is possible to build with 64-bit file offsets on 32-bit platforms such as
armv7, and indeed this is the default for some build environments such as
Yocto. Use fsblkcnt_t, which is an alias to a type of the correct width, when
computing blockSize.
It is good practice to build with 64-bit time_t/timeval on 32-bit platforms to
avoid the Y2038 issue. This is the default when building on Yocto for armv7,
for example. Unfortunately suseconds_t is not an alias to a type of the correct
width (unlike time_t), so for Glibc make it a private alias of time_t to fix
the build.
@lhoward
Copy link
Author

lhoward commented Jun 28, 2025

If for process reasons you need a PR against main, can do, just lmk once this is reviewed. Sorry to do it back to front.

@lhoward lhoward changed the title Support for building with 64-bit time_t/off_t on 32-bit platforms 6.1: Support for building with 64-bit time_t/off_t on 32-bit platforms Jul 1, 2025
@MaxDesiatov
Copy link
Contributor

MaxDesiatov commented Jul 1, 2025

If for process reasons you need a PR against main, can do, just lmk once this is reviewed. Sorry to do it back to front.

Yes, PRs should be merged first to main, and only then reviewed on release branches. This is not entirely about process, but also about consistency in how fixes are, in a way, incubated on main to assess the risk before cherry-picking to releases.

@lhoward
Copy link
Author

lhoward commented Jul 1, 2025

If for process reasons you need a PR against main, can do, just lmk once this is reviewed. Sorry to do it back to front.

Yes, PRs should be merged first to main, and only then reviewed on release branches. This is not entirely about process, but also about consistency in how fixes are, in a way, incubated on main to assess the risk before cherry-picking to releases.

Gotcha. PRs on main filed, please ignore this until those are merged.

@al45tair
Copy link
Contributor

al45tair commented Jul 2, 2025

Yes, PRs should be merged first to main, and only then reviewed on release branches. This is not entirely about process, but also about consistency in how fixes are, in a way, incubated on main to assess the risk before cherry-picking to releases.

It's also to prevent unexpected regressions, where we've merged a fix to a release branch and then it doesn't get merged on main, or gets reverted on main, and then the next release suddenly goes backwards and has a bug that was already fixed.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants