You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
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.
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.
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.htypedef 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.)
Glusterfs uses the LFS64 transitional API:
off64_t,F_GETLK64/F_SETLK64/F_SETLKW64,copy_file_rangetyped onoff64_tAs a consequence:
api/src/glfs.hcannot be included by non-glibc gfapi consumers: it#defines the glibc-internal__USE_FILE_OFFSET64and thentypedef __off64_t off64_t-__off64_texists 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.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 firstoff64_tuse (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 fixthis. Gentoo bug 912356 has tracked it since 2023.
The transitional names may be redundant on glibc. on modern distros glibc's
_GNU_SOURCEimplies_LARGEFILE64_SOURCE, sooff64_t/F_*LK64are just aliases for the 64-bitoff_twhich 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_LARGEFILE64inglusterfs-api.pc(since 2012) is passed to four in-treeMakefile.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_SOURCEtoGF_CPPDEFINES(inert on glibc, unbreaks musl) and stop shipping the glibc-private__USE_*macros; makeglfs.hinclude<sys/stat.h>and stop referencing__off64_ton 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 makesglfs.hincludable.Retirement (5 commits). Replace
off64_t->off_tfor thecopy_file_rangeplumbing (including the publicglfs_copy_file_range()prototype), drop the deadF_*LK64alternates (the wire usesGF_LK_*; the*64names were glibc-only aliases), add an#errorthat turns a silentoff_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
.pcfile, and I'd rather agree the approach than surprise a reviewer:off64_t *->off_t *in the publicglfs.hprototype. The C ABI is unchanged on most 64-bit systems (whereoff64_tandoff_tare the same type) and the symbol version staysGFAPI_6.0; the visible edit to is the point of contention. What changes: a consumer on a libc that doesn't self-declareoff64_tand relied onglfs.hto declare it. The obvious gfapi consumer, Samba'svfs_glusterfs, does not call this function; the only in-tree caller passesNULLoffsets.An
#errorin a public header when a consumer's own feature macros would give it a differentoff_t/struct statwidth 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#warninginstead 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.pcwithout a deprecation cycle. Inert on modern glibc build; on musl a consumer that used the gfapi Cflags to getoff64_tfor its own code must now ask for it itself. Release-note material — and if a deprecation cycle is preferred, we can keep_LARGEFILE64_SOURCEin the.pcfor 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
-Dflags (off64_t/__off64_t/F_SETLK64/F_SETLKW64/F_GETLK64), itscompat.htypedef int64_t off64_t, and thesyscall.hinclude added to make that typedef visible (syscall.hthen 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.