binary-file-built-without-LFS-support
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 _FILE_OFFSET_BITS
to 64 will be a no-op, and as such optional). This can be done by using
the 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
compiled.
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 _LARGEFILE64_SOURCE
and exporting both 32 and 64-bit variants of the interfaces can avoid
the SOVERSION bump, at the cost of more complex maintenance.
Severity: | info |
Experimental: | true |