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