The tag is present in Lintian version 2.109.6. That is the most recent version we know about.
The listed ELF binary appears to be (partially) built without "Large File Support" (LFS). If so, it may not be able to handle large files or files with large metadata values, such as inode numbers, correctly.
To support large files, code review might be needed to make sure that
those files are not slurped into memory or mmap(2)ed, and that correct
64-bit data types are used (ex:
off_t instead of
ssize_t), etc. Once
that has been done ensure
_FILE_OFFSET_BITS is defined and
set to 64 before any system headers are included (note that on systems
were the ABI has LFS enabled by default, setting
to 64 will be a no-op, and as such optional). This can be done by using
AC_SYS_LARGEFILE macro with autoconf which will set any
macro required to enable LFS when necessary, or by enabling the
lfs feature from the
future dpkg-buildflags feature
area which sets the
CPPFLAGS variable (since dpkg-dev 1.19.0).
Note though, that
getconf LFS_CFLAGS must not be used,
as it does not support cross-building. Using
_FILE_OFFSET_BITS should require no system function renames (eg.
from open(2) to open64(2)), and if this tag is still emitted, the most
probable cause is because the macro is not seen by the system code being
Take into account that even if this tag is not emitted, that does not mean the binary is LFS-safe (ie. no OOM conditions, file truncation or overwrite will happen).
Also note that enabling LFS on a shared library is not always safe as
it might break ABI in case some of the exported types change size, in
those cases a SOVERSION bump might be required. Or alternatively, on
systems with an ABI without LFS, defining
and exporting both 32 and 64-bit variants of the interfaces can avoid
the SOVERSION bump, at the cost of more complex maintenance.
Please refer to http://www.unix.org/version2/whatsnew/lfs20mar.html and https://www.gnu.org/software/libc/manual/html_node/Feature-Test-Macros.html for details.
This tag is experimental.