Please note I don't maintain libc. Norman Ramsey <n...@cs.tufts.edu> writes:
> /usr/include/fts.h, which is part of glibc, does not work with > transparent Large File Support. This means that applications like pax > cannot be compiled with LFS (see bug 317466). The problem there seems to be struct stat *fts_statp in FTSENT. There is one variant of struct stat for 32-bit file offsets and another for 64-bit. fts_read and fts_children would have to know which variant the caller expects, but they don't get that information. Fixing this requires extending the ABI, and IIRC eglibc makes such changes only if glibc makes them too. The fts functions are not documented in the glibc 2.8 manual. The manpages-dev 2.39-1 package says they come from 4.4BSD and may eventually be added to POSIX.1. Perhaps they will be extended to large files at that time. If a program needs large-file support for recursive directory operations now, it can perhaps be ported from <fts.h> to <ftw.h>, which already supports large files but doesn't provide as many features. In particular, it doesn't seem to detect hard links. Alternatively, use amd64, where file offsets are always 64-bit. Copying the source of the fts functions to the program and adding large-file support locally may be another option.
pgp5oL9uhqlqr.pgp
Description: PGP signature
