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 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
