Bug#670963: lintian: Warn (or at least inform) of non-LFS-enabled binaries

[Niels Thykier <niels@thykier.net>]

On 2013-01-23 02:47, Guillem Jover wrote:
> Hi!
> 

Hi,

> On Sat, 2013-01-19 at 00:26:43 +0100, Niels Thykier wrote:
>> #lintian (2.5.12) UNRELEASED; urgency=low
>> #
>> #  * checks/binaries{,.desc}:
>> #    + [NT] Check for binaries built without LFS.  This can
>> #      only be checked for 32bit binaries as 64bit binaries
>> #      have LFS by definition.  Thanks to Guillem Jover for
>> #      the report.  (Closes: #670963)
>> #
> 
> Cool, thanks! Here's a small patch series hopefully improving the
> check a bit. It does the following:
> 
>   * Adds the non-LFS-safe fts(3) family of funtions, these do not have
>     an LFS counterpart.

Thanks for noticing those being missing.

>   * Expands the tag description to describe a bit more how to add LFS,
>     and possible problems when enabling it on a shared library.

Thanks, it is definitely better than my makeshift description -
particularly the SONAME bumping.

>   * Handles partially enabled LFS binaries, so that if an object which
>     is part of the binary has been correctly compiled with LFS but not
>     another part it will trigger. Add a regression test for this.
> 

It was my understanding that "you" (i.e. the programmer) could
deliberately support both 32 and 64 bit interfaces by using
-D_LARGEFILE64_SOURCE.  But I suppose it is unlikely that anyone would
bother having both interfaces around.

> Also something to note is that some of the functions will most
> probably not match as they get renamed to something else, for example
> stat(2) will end up as __xstat on the binary's symbol table. There's
> probably others like that.
> 

Really?  Because I looked at the include files and saw loads of:

#define symbol symbol64

But yeah, stat appears to be "__extern_inline"'d, so that would fail
detection.

> Of course feel free to squash them into a single patch if that's your
> preferred form.
> 
> Thanks,
> Guillem

"""
+/* Name function so that it comes last in the symbol table, to make
+ * sure the presence of an LFS function does not mark the whole binary
+ * as LFS-enabled. */
"""

This comment (from the test in patch 3) does not seem to be accurate
(any longer).  Regardless of which order they appear in the check should
be produce the same result (as we would no longer whitelist any binary
with LFS-enabled code).

~Niels