madler
_LARGEFILE64_SOURCE and _FILE_OFFSET_BITS coexistence
Dear All,
I do have a question regarding following code snippet from zlib/gzguts.h
#ifdef _LARGEFILE64_SOURCE
# ifndef _LARGEFILE_SOURCE
# define _LARGEFILE_SOURCE 1
# endif
# ifdef _FILE_OFFSET_BITS
# undef _FILE_OFFSET_BITS
# endif
#endif
Why it is necessary to undef the _FILE_OFFSET_BITS flag in gzguts.h file (which is an internal zlib file)?
From what I can read from the Internet, the _LARGEFILE{64}_SOURCE flags are now obsolete and one shall only rely on _FILE_OFFSET_BITS==64.
Is it safe to uncomment the _FILE_OFFSET_BITS and build zlib with set it to 64?
Thanks in advance for your help.
This appears to break system-global builds when the new _TIME_BITS macro introduced in glibc 2.34 is set to 64.
This prevents Buildroot and Yocto from using _TIME_BITS set to 64 for the system, which will be needed to fix the Y2038 problem.
See https://patchwork.ozlabs.org/project/buildroot/patch/[email protected]/ and https://unix.stackexchange.com/questions/692377/relationship-between-flags-d-file-offset-bits-and-d-largefile64-source for discussions.
It there a fix for compiling zlib with -D_FILE_OFFSET_BITS=64 -D_TIME_BITS=64?
https://github.com/madler/zlib/blob/21767c654d31d2dccdde4330529775c6c5fd5389/gzguts.h#L6-L13
Is is just a matter of removing lines 10-12 or replacing line 11 with #define _FILE_OFFSET_BITS 64
I wrote about a quick workaround at https://stackoverflow.com/a/72854884/556495. Basically just undef _TIME_BITS whenever _FILE_OFFSET_BITS is undefed. No time functions are used here so that approach won't break anything.
For my compiles I flagged zlib as not compatible and removed both defines. Was hoping for a cleaner way. As it was the last of the userland that needed patching.