Skip to content

RFC: retire the LFS64 transitional API (off64_t / F_*LK64); fix musl builds and the public glfs.h #4775

Description

@ThalesBarretto

Glusterfs uses the LFS64 transitional API:

  • off64_t, F_GETLK64/F_SETLK64/F_SETLKW64,
  • copy_file_range typed on off64_t
  • and a set of glibc-private feature macros.

As a consequence:

  1. api/src/glfs.h cannot be included by non-glibc gfapi consumers: it #defines the glibc-internal __USE_FILE_OFFSET64 and then typedef __off64_t off64_t - __off64_t exists only in glibc, so on musl and on NetBSD a consumer #include <glusterfs/api/glfs.h> fails outright (glfs.h:71: unknown type name '__off64_t'). This is a defect in a shipped public header, independent of whether the server itself is built for those platforms.

  2. distros cannot build on musl >= 1.2.4 (Alpine 3.21+, Gentoo musl). musl 1.2.4 (2023) stopped exposing the LFS64 names under _GNU_SOURCE: they now require _LARGEFILE64_SOURCE, The build dies at the first off64_t use (glusterfs/syscall.h:277: unknown type name 'off64_t'). Include sys/types.h for off64_t. #4215 added the <sys/types.h> include the man page asks for, but the feature macro is the actual gate, so it did not fix
    this. Gentoo bug 912356 has tracked it since 2023.

  3. The transitional names may be redundant on glibc. on modern distros glibc's _GNU_SOURCE implies
    _LARGEFILE64_SOURCE, so off64_t/F_*LK64 are just aliases for the 64-bit off_t which we already get from -D_FILE_OFFSET_BITS=64. And i think glibc's <features.h> #undefs the __USE_* macros before deriving them from the public switches, so -D__USE_FILE_OFFSET64 -D__USE_LARGEFILE64 in glusterfs-api.pc (since 2012) is passed to four in-tree Makefile.ams but now (64bit only) may have no effect.

The proposal, in two layers

The branch is one series but it separates cleanly:

  • Minimal (2 commits). Add -D_LARGEFILE64_SOURCE to GF_CPPDEFINES (inert on glibc, unbreaks musl) and stop shipping the glibc-private __USE_* macros; make glfs.h include <sys/stat.h> and stop referencing __off64_t on non-glibc libcs. No prototype or ABI change. This is the smallest thing that clears the fatal LFS64 build failure on musl (unblocking the remaining, non-LFS64 fixes in Add support for Alpine Linux 3.21 / linux-musl #4450) and makes glfs.h includable.

  • Retirement (5 commits). Replace off64_t -> off_t for the copy_file_range plumbing (including the public glfs_copy_file_range() prototype), drop the dead F_*LK64 alternates (the wire uses GF_LK_*; the *64 names were glibc-only aliases), add an #error that turns a silent off_t-width mismatch in a consumer into a loud build failure (inert on the 64-bit builds upstream ships), and finally drop the _LARGEFILE64_SOURCErequest as a completeness proof.

Why an RFC?

The retirement layer touches a shipped public header and a .pc file, and I'd rather agree the approach than surprise a reviewer:

  • off64_t * -> off_t * in the public glfs.h prototype. The C ABI is unchanged on most 64-bit systems (where off64_t and off_t are the same type) and the symbol version stays GFAPI_6.0; the visible edit to is the point of contention. What changes: a consumer on a libc that doesn't self-declare off64_t and relied on glfs.h to declare it. The obvious gfapi consumer, Samba's vfs_glusterfs, does not call this function; the only in-tree caller passes NULL offsets.

  • An #error in a public header when a consumer's own feature macros would give it a different off_t / struct stat width than the library was built with. It is inert on the modern 64-bit configs and fires only for a consumer has configured itself into a width that disagrees with libgfapi, where the alternative is a translation unit that compiles and then corrupts. You could do #warning instead of breaking a downstream build, or the commit can be dropped entirely — it was included to fail loud, not a bid to support 32-bit builds and is a guard that costs modern builds nothing.

  • Drop _LARGEFILE64_SOURCE / the __USE_* macros from the .pc without a deprecation cycle. Inert on modern glibc build; on musl a consumer that used the gfapi Cflags to get off64_t for its own code must now ask for it itself. Release-note material — and if a deprecation cycle is preferred, we can keep _LARGEFILE64_SOURCE in the .pc for a release while dropping it from our own builds.

Unblocks and simplifies PR #4450

Rebasing #4450 patch on top of this series allowed us to drop some -D flags (off64_t/__off64_t/F_SETLK64/F_SETLKW64/F_GETLK64), its compat.h typedef int64_t off64_t, and the syscall.h include added to make that typedef visible (syscall.h then drops out of #4450 entirely). The reduced #4450 still builds on musl (Alpine 3.22). What remains is the genuinely musl/BSD-specific work — none of which this series touches. (Gentoo's downstream musl patch collapses thesame way: see the Related bugs.)

Related: #268 (Alpine compatibility), #4450 (Alpine/musl support), Gentoo 908588 / 912356.

Activity

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

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions