public inbox for gentoo-portage-dev@lists.gentoo.org
 help / color / mirror / Atom feed
From: Zac Medico <zmedico@gentoo.org>
To: gentoo-portage-dev@lists.gentoo.org
Subject: Re: [gentoo-portage-dev] [PATCH v2] install-qa-check.d: issue warnings for 32bit ELFs not using LFS
Date: Sat, 30 May 2015 11:22:55 -0700	[thread overview]
Message-ID: <5569FFFF.8030504@gentoo.org> (raw)
In-Reply-To: <20150530143534.GE2101@vapier>

On 05/30/2015 07:36 AM, Mike Frysinger wrote:
> On 26 May 2015 08:58, Zac Medico wrote:
>> On 05/26/2015 07:24 AM, Mike Frysinger wrote:
>>> +	# Only check on 32-bit systems.  Filtering by $ARCH here isn't perfect, but
>>> +	# it should be good enough for our needs.
>>> +	case ${ARCH} in
>>> +	arm|mips|ppc|sh|x86) ;;
>>> +	*) return ;;
>>> +	esac
>>
>> Shouldn't we also enable this for 64-bit archs when multilib is enabled?
> 
> yes, but i think we should start here first.  getting multilib right is kind of 
> a pain.  this should give us enough coverage i think to get people to start 
> filing bugs which implicitly covers multilib users.  once the dust has settled, 
> we can look at expanding the multilib coverage.  although that would really 
> require a python implementation, and the current install hooks logic implicitly 
> requires every file to be bash.
>
> to use your pkg-config example, it installs 32bit & 64bit ELFs into /usr/bin.  
> we can't scan all 32bit ELFs because it would incorrectly flag ILP32 ABIs like 
> x32 & n32.

Our compute_multilib_category function has logic that could be used to
separate and filter them:

https://gitweb.gentoo.org/proj/portage.git/tree/pym/portage/dep/soname/multilib_category.py

> ideally we'd scan the whole multilib dir, but that too runs into problems.
> when /usr/lib is the path for both x86 multilib and non-multilib content (like 
> libexec stuff), we can't blindly scan & reject all ELFs in there.  the previous 
> note about ILP32 applies here too.
> 
> so if we're happy with this implementation, i'll start a thread on gentoo-dev so 
> people aren't caught by surprise, and we can merge this for the next release.
> -mike
> 

Okay, fine.
-- 
Thanks,
Zac


  reply	other threads:[~2015-05-30 18:23 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-05-26  7:44 [gentoo-portage-dev] [PATCH] install-qa-check.d: issue warnings for 32bit ELFs not using LFS Mike Frysinger
2015-05-26 14:24 ` [gentoo-portage-dev] [PATCH v2] " Mike Frysinger
2015-05-26 15:58   ` Zac Medico
2015-05-26 18:45     ` Zac Medico
2015-05-30 14:36     ` Mike Frysinger
2015-05-30 18:22       ` Zac Medico [this message]
2015-05-30 18:31         ` Mike Frysinger
2015-06-11  7:21       ` Brian Dolbec
2015-06-11 10:17         ` Mike Frysinger

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=5569FFFF.8030504@gentoo.org \
    --to=zmedico@gentoo.org \
    --cc=gentoo-portage-dev@lists.gentoo.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox