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.

Sign up for GitHub

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

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

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

wants to merge 2 commits into from

Conversation

lhoward
Copy link

@lhoward lhoward commented Jun 28, 2025 •
edited
Loading

  • 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
@lhoward
build with 64-bit fsblkcnt_t on 32-bit glibc platforms
3eb8a04 
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.
@lhoward
build with 64-bit time_t on 32-bit platforms
ad2b4b3 
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 lhoward mentioned this pull request Jun 28, 2025
Merged
@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
@lhoward lhoward mentioned this pull request Jul 1, 2025
Closed
@MaxDesiatov
Copy link
Contributor

MaxDesiatov commented Jul 1, 2025 •
edited
Loading

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 •
edited
Loading

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
Reviewers
No reviews
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

Successfully merging this pull request may close these issues.
3 participants
@lhoward @MaxDesiatov @al45tair