Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bugzilla DB migration completed. Please report issues to Infra team via email via infra@gentoo.org or IRC
Bug 550482 - portage: lfs qa check needs to handle multilib setups properly
Summary: portage: lfs qa check needs to handle multilib setups properly
Status: CONFIRMED
Alias: None
Product: Portage Development
Classification: Unclassified
Component: Core - Ebuild Support (show other bugs)
Hardware: All All
: Normal normal (vote)
Assignee: Portage team
URL:
Whiteboard:
Keywords:
Depends on:
Blocks: lfs-tracker 549092
  Show dependency tree
 
Reported: 2015-05-26 18:42 UTC by Zac Medico
Modified: 2020-06-14 13:18 UTC (History)
3 users (show)

See Also:
Package list:
Runtime testing required: ---


Attachments
fix ebuild to call append-lfs-flags from flag-o-matic.eclass (pkgconfig-0.28-r2.ebuild.patch,248 bytes, patch)
2015-05-26 20:37 UTC, Zac Medico
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Zac Medico gentoo-dev 2015-05-26 18:42:44 UTC
The new QA check for bug 471102 reports these issues:

 * QA Notice: The following files were not built with LFS support:
 *   Please see https://bugs.gentoo.org/471102 for details.
 * readdir@@GLIBC_2.2.5,fopen@@GLIBC_2.2.5 usr/bin/x86_64-pc-linux-gnu-pkg-config
 * readdir@@GLIBC_2.2.5,fopen@@GLIBC_2.2.5 usr/bin/pkg-config
 * fopen@@GLIBC_2.1,readdir@@GLIBC_2.0 usr/bin/i686-pc-linux-gnu-pkg-config

Adding a call to append-lfs-flags from flag-o-matic.eclass solves the problem.

I can confirm that this is a real problem, because it makes pkgconfig fail to work on an xfs filesystem due to 64-bit inode numbers. The problem is solved after adding an append-lfs-flags (from flag-o-matic.eclass) call at the beginning of src_configure.
Comment 1 Zac Medico gentoo-dev 2015-05-26 20:37:47 UTC
Created attachment 404022 [details, diff]
fix ebuild to call append-lfs-flags from flag-o-matic.eclass
Comment 2 Rafał Mużyło 2015-05-26 21:09:35 UTC
...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.
Comment 3 Mike Gilbert gentoo-dev 2015-05-26 21:38:47 UTC
(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: -
Comment 4 Zac Medico gentoo-dev 2015-05-26 21:43:04 UTC
(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.
Comment 5 Rafał Mużyło 2015-05-26 22:37:59 UTC
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.
Comment 6 Rafał Mużyło 2015-05-26 22:59:29 UTC
...stupid typo...
meant to be: "...I tend to miss..."
Comment 7 Zac Medico gentoo-dev 2015-05-26 23:09:42 UTC
(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
Comment 8 Rafał Mużyło 2015-05-27 02:01:28 UTC
(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...
Comment 9 Zac Medico gentoo-dev 2015-05-27 02:07:28 UTC
(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.
Comment 10 Rafał Mużyło 2015-05-27 02:37:40 UTC
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 ?
Comment 11 SpanKY gentoo-dev 2015-05-27 02:59:11 UTC
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.
Comment 12 SpanKY gentoo-dev 2015-05-27 03:03:11 UTC
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.
Comment 13 Alexandre Rostovtsev (RETIRED) gentoo-dev 2015-05-27 04:40:37 UTC
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 :)
Comment 14 Rafał Mużyło 2015-05-27 05:18:31 UTC
> 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.
Comment 15 SpanKY gentoo-dev 2015-05-27 05:46:37 UTC
(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.