libsanitizer: fts.h: drop the bogus _FILE_OFFSET_BITS==64 #error
<fts.h> in uClibc-ng was imported verbatim from glibc in 2011
(commit a4aa01c1 by Salvatore Cro, "Added fts support for traversing
UNIX file hierarchies", added to support elfutils' libdwfl) and
inherited glibc's incompatibility guard:
/* The fts interface is incompatible with the LFS interface which
transparently uses the 64-bit file access functions. */
#ifdef __USE_FILE_OFFSET64
# error "<fts.h> cannot be used with -D_FILE_OFFSET_BITS==64"
#endif
The guard is correct in glibc because glibc's own fts implementation
genuinely lacks 64-bit variants (no fts_open64 etc.). uClibc-ng's
libc/misc/fts/fts.c, however, is BSD-derived (not glibc-derived) and
just uses whatever off_t / ino_t the libc was configured with -- which,
since the 2016 hard-coding of UCLIBC_HAS_LFS=y, is always 64-bit
internally. The guard is then either wrong (LFS-on, the only
supported configuration in practice) or dead code (LFS-off, not
buildable for ~10 years).
Real-world consumer that triggered the discovery: building
elfutils-0.193 with libsanitizer enabled (via heaptrack). elfutils
includes <fts.h> after <sys/types.h> on a 64-bit-off_t target and
trips the guard, even though uClibc-ng's fts.c handles 64-bit off_t
fine.
Also matches musl libc's position: musl ships no <fts.h> at all,
because its maintainers consider glibc's fts so structurally broken
that any user is expected to bundle its own copy (gnulib-fts /
musl-fts). Programs that already do that won't include this header;
programs that don't (like elfutils) deserve a working 64-bit fts.
Signed-off-by: Ramin Moussavi <ramin.moussavi@yacoub.de>
Ramin Moussavi