| Summary: | portage: lfs qa check needs to handle multilib setups properly | ||
|---|---|---|---|
| Product: | Portage Development | Reporter: | Zac Medico <zmedico> |
| Component: | Core - Ebuild Support | Assignee: | Portage team <dev-portage> |
| Status: | CONFIRMED --- | ||
| Severity: | normal | CC: | floppym, sam, vapier, wizardedit |
| Priority: | Normal | ||
| Version: | unspecified | ||
| Hardware: | All | ||
| OS: | All | ||
| See Also: |
https://bugs.gentoo.org/show_bug.cgi?id=550508 https://bugs.gentoo.org/show_bug.cgi?id=629704 https://bugs.gentoo.org/show_bug.cgi?id=549092 https://bugs.gentoo.org/show_bug.cgi?id=847493 |
||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
| Bug Depends on: | |||
| Bug Blocks: | 471102, 549092 | ||
| Attachments: | fix ebuild to call append-lfs-flags from flag-o-matic.eclass | ||
|
Description
Zac Medico
2015-05-26 18:42:44 UTC
Created attachment 404022 [details, diff]
fix ebuild to call append-lfs-flags from flag-o-matic.eclass
...just a thought: I might be misunderstanding something, but wouldn't 'usr/bin/x86_64-pc-linux-gnu-pkg-config' be a false positive ? That is (unless I'm missing something) can 64bit executables/libs be affected by this ? (going by by what I recall *and* the blog post noted in bug 471102, not really) On not quite related note: I'd say it would make sense to turn pkg-config into a symlink to x86_64-pc-linux-gnu-pkg-config on amd64. (In reply to Rafał Mużyło from comment #2) > On not quite related note: I'd say it would make sense to turn pkg-config > into a symlink to x86_64-pc-linux-gnu-pkg-config on amd64. It is already a hard link. I'm not sure how a symlink would be an improvement. File: ‘/usr/bin/pkg-config’ Size: 43536 Blocks: 88 IO Block: 4096 regular file Device: 1ah/26d Inode: 82472304 Links: 2 Access: (0755/-rwxr-xr-x) Uid: ( 0/ root) Gid: ( 0/ root) Access: 2015-05-26 01:09:16.833922349 -0400 Modify: 2014-07-29 21:21:51.174010496 -0400 Change: 2014-07-29 21:21:57.908910728 -0400 Birth: - File: ‘/usr/bin/x86_64-pc-linux-gnu-pkg-config’ Size: 43536 Blocks: 88 IO Block: 4096 regular file Device: 1ah/26d Inode: 82472304 Links: 2 Access: (0755/-rwxr-xr-x) Uid: ( 0/ root) Gid: ( 0/ root) Access: 2015-05-26 01:09:16.833922349 -0400 Modify: 2014-07-29 21:21:51.174010496 -0400 Change: 2014-07-29 21:21:57.908910728 -0400 Birth: - (In reply to Rafał Mużyło from comment #2) > ...just a thought: I might be misunderstanding something, but wouldn't > 'usr/bin/x86_64-pc-linux-gnu-pkg-config' be a false positive ? > > That is (unless I'm missing something) can 64bit executables/libs be > affected by this ? Maybe so. @toolchain: If that's the case, then the QA check should filter based on the multilib ABI. wrt. comment 3: OK, I tend to not miss that one file or the other is a hardlink On general note: perhaps I'm missing something, but what is this check we're talking about ? I don't see anything in proj/portage.git. ...stupid typo... meant to be: "...I tend to miss..." (In reply to Rafał Mużyło from comment #5) > On general note: perhaps I'm missing something, but what is this check we're > talking about ? I don't see anything in proj/portage.git. It hasn't been merged yet. The patch has been posted here: https://archives.gentoo.org/gentoo-portage-dev/message/51efd98fc000449432349c01006b3fe6 (In reply to Zac Medico from comment #7) > (In reply to Rafał Mużyło from comment #5) > > On general note: perhaps I'm missing something, but what is this check we're > > talking about ? I don't see anything in proj/portage.git. > > It hasn't been merged yet. The patch has been posted here: > > https://archives.gentoo.org/gentoo-portage-dev/message/ > 51efd98fc000449432349c01006b3fe6 ...so, yeah, another silly question then: is there some specific version of pax-utils needed for versioned symbols ? Cause perhaps that somehow works within portage, but doesn't seem to outside (and that's even with 1.0.3). Closest I can get is with grepping 'readelf --dyn-syms' output... (In reply to Rafał Mużyło from comment #8) I have app-misc/pax-utils-0.8.1 installed here. I just applied the portage patch, and my installed version of pax-utils worked fine. A random example: scanelf -F "%s %p" -qRgys "-^(fopen)(@@.*)?$" /usr/bin/i686-pc-linux-gnu-pkg-config fopen /usr/bin/i686-pc-linux-gnu-pkg-config so, unless I messed up the regexp... ...or do you want to say it works only within portage ? the versioned symbols aren't relevant, so don't be distracted by those pkg-config is actually broken, but this warning shouldn't be coming up here. i've created a fresh bug 550508 to track fixing pkg-config. to be clear, this warning came up when Zac modified the script to run for 64bit arches too. i had disabled that because it would throw lots of false positives like this :). i think we can roll it out first for non-32bit arches to get some feedback before we worry about handling multilib setups. IMHO, it's easiest to just use objdump. If you see "fopen" instead of "fopen64" in objdump -T output on a 32-bit binary, then it doesn't have LFS :) > the versioned symbols aren't relevant, so don't be distracted by those
still, I'd like to know what exactly makes a difference there
Anyway, 'objdump -T' seems not a bad idea...
BTW, I've run the script from the blog on a 32bit machine; the 'use 32-bit stat() family interfaces only' list was quite long, though some of those might *functionally* be false positives, but 'use both 32-bit and 64-bit stat() family interfaces' might be a different matter:
/usr/bin/mtp-connect
/usr/bin/eu-strip
/usr/bin/sudo
/usr/bin/luatex
/usr/sbin/dovecot
/usr/sbin/alsactl
Even if those are *functionally* false positives (by 'functionally' I mean they might not be using those calls in a way that matters for this bug), it still stinks.
That script used 'file -L' to identify if the executable is 32 or 64 bit, which basically boils down to checking if the first byte after '.ELF' is 0x01 or 0x02.
(In reply to Alexandre Rostovtsev from comment #13) i don't see how objdump could possibly be better than using scanelf. it certainly will be magnitudes slower. this bug is not related to scanelf properly detecting the symbols ... it's entirely with detecting the symbols in legacy 32bit ELFs (and not just 32bit ELFs because some ABIs like x32 are fine). (In reply to Rafał Mużyło from comment #14) this bug isn't about tracking down all bad packages. there is a tracker already for centralizing work, and each package should get its own bug. (In reply to SpanKY from comment #12) > to be clear, this warning came up when Zac modified the script to run for > 64bit arches too. i had disabled that because it would throw lots of false > positives like this :). i think we can roll it out first for non-32bit > arches to get some feedback before we worry about handling multilib setups. Agreed. I don't see the need to block on multilib. The fixes are fixes anyway. We just want to avoid false positives, so we'll avoid scanning on multilib for now. btw: I suspect the weird distinction between inside/outside portage is bug 847493. |
