Bug#670963: lintian: Warn (or at least inform) of non-LFS-enabled binaries
On 2013-01-23 11:45, Guillem Jover wrote:
> On Wed, 2013-01-23 at 09:37:59 +0100, Niels Thykier wrote:
>> On 2013-01-23 02:47, Guillem Jover wrote:
>>> * 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.
>
> Ah, right. I can think of two cases where a binary might kind of
> “ligitimately” mix LFS and non-LFS enabled objects.
>
> [...]
>
> In any case this should be overridable so “legitimate” cases can be
> ignored, but I'd expect those to be few.
>
Right, I think we will go with emitting the tag unless there is complete
LFS support. We can always undo it later. BTW, the previous code has
been running on lintian.d.o for a while - so far at least 300 packages
have triggered (at least once). Though it is hard to tell how much of
the archive is affected from this.
http://lintian.debian.org/tags/binary-file-built-without-LFS-support.html
>>> 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.
>
> I didn't check if there's any other, so just wanted to bring it up
> here so this does not get missed. Maybe a more resistant way to handle
> this could be to add a generator program in lintian that looks for
> foo/foo64 symbol variants from libc at build time?
>
Given that are now flagging any known "bad" LFS usage, we do not need to
know what the "safe" variant is called. I have replaced {,f,l}stat
functions with the __{,f,l}xstat variants.
>>> Of course feel free to squash them into a single patch if that's your
>>> preferred form.
>>
>> """
>> +/* 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).
>
> Right sorry, I added that case as a regression check, and the explanation
> seemed fitting to explain why the function name, it might need to be
> clarified to explain just that, or do you want that removed, do you want
> me to resend?
>
> Thanks,
> Guillem
>
>
Nah, I just ammended your patch to exclude the comment. All 3 are
committed (note that I also ammended the 0002 to break the pargraph into
smaller ones).
~Niels
Reply to: