Bug#670963: lintian: Warn (or at least inform) of non-LFS-enabled binaries
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.
One is a program that can handle large files, and other files which
are guaranteed to always be small (as in, if they are large there's a
problem elsewhere anyway), in that case there might not seem to be a
point in using the large file variants for the latter, OTOH using LFS
for everything should be fine, so I think this should be most of the
time an oversight (see the now fixed dpkg example in the referenced
bug report about a bogusly placed config.h in a lex file).
The other, as you say, is shared libraries which might want to expose
both interfaces, most probably for backwards compatibility, because
otherwise I don't really see the point either, but those should take
care of defining data types independent of the LFS data model, so that
say, an off_t does not suddenly turn from the expected 32-bit to the
undesired 64-bit depending on the caller environment.
In any case this should be overridable so “legitimate” cases can be
ignored, but I'd expect those to be few.
> > 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?
> > 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
Reply to: