public inbox for openembedded-core@lists.openembedded.org
 help / color / mirror / Atom feed
From: Richard Purdie <richard.purdie@linuxfoundation.org>
To: Martin Jansa <Martin.Jansa@gmail.com>,
	 openembedded-core@lists.openembedded.org
Subject: Re: [OE-core] [PATCH] uninative: call patchelf-uninative only when needed
Date: Fri, 23 Jun 2023 11:18:09 +0100	[thread overview]
Message-ID: <35c96621a643bc6ef527eed83cc420eba85075ca.camel@linuxfoundation.org> (raw)
In-Reply-To: <20230623093323.4058529-1-Martin.Jansa@gmail.com>

On Fri, 2023-06-23 at 11:33 +0200, Martin Jansa wrote:
> mke2fs.real, mkfs.ext2.real, mkfs.ext3.real, mkfs.ext4.real are indentical
> binary with multiple hardlinks and we end calling patchelf-uninative 4
> times even when the interpreter is already set correctly from the build
> 
> To avoid corrupted binaries created by patchelf-0.18.0 when set-interpreter
> is called multiple times (on some systems like ubuntu-18.04 this leads to
> segfaults elsewhere just ldd complains that the executable is no longer
> dynamically linked, but doesn't fail when executed).
> 
> The issue was reported upstream with mkfs.ext4.real as possible reproducer:
> https://github.com/NixOS/patchelf/issues/492#issuecomment-1602862272
> alternatively we can revert
> https://github.com/NixOS/patchelf/commit/65cdee904431d16668f95d816a495bc35a05a192
> and create new uninative release with update patchelf-uninative, but
> better to wait a bit for upstream to have a look and possibly backport
> proper fix later, until then this change fixes the mkfs.ext4 issues I was
> seeing in kirkstone, mickledore, nanbield since uninative-3.9 upgrade, as
> reported in:
> https://lists.openembedded.org/g/openembedded-core/message/182862
> 
> Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com>
> ---
>  meta/classes-global/uninative.bbclass | 11 ++++++++---
>  1 file changed, 8 insertions(+), 3 deletions(-)
> 
> diff --git a/meta/classes-global/uninative.bbclass b/meta/classes-global/uninative.bbclass
> index 366f7ac793..b54acdd542 100644
> --- a/meta/classes-global/uninative.bbclass
> +++ b/meta/classes-global/uninative.bbclass
> @@ -175,7 +175,12 @@ python uninative_changeinterp () {
>              if not elf.isDynamic():
>                  continue
>  
> -            os.chmod(f, s[stat.ST_MODE] | stat.S_IWUSR)
> -            subprocess.check_output(("patchelf-uninative", "--set-interpreter", d.getVar("UNINATIVE_LOADER"), f), stderr=subprocess.STDOUT)
> -            os.chmod(f, s[stat.ST_MODE])
> +            current = subprocess.check_output(("patchelf-uninative", "--print-interpreter", f), stderr=subprocess.STDOUT).decode('utf-8').split('\n')[0]
> +            if current != d.getVar("UNINATIVE_LOADER"):
> +                bb.debug(2, "Changing interpreter from %s to %s with %s" % (current, d.getVar("UNINATIVE_LOADER"), ("patchelf-uninative", "--set-interpreter", d.getVar("UNINATIVE_LOADER"), f)))
> +                os.chmod(f, s[stat.ST_MODE] | stat.S_IWUSR)
> +                subprocess.check_output(("patchelf-uninative", "--set-interpreter", d.getVar("UNINATIVE_LOADER"), f), stderr=subprocess.STDOUT)
> +                os.chmod(f, s[stat.ST_MODE])
> +            else:
> +                bb.debug(2, "Interpreter was already set to %s in %s" % (d.getVar("UNINATIVE_LOADER"), f))
>  }

I know why you've done it this way but ideally we should make patchelf
handle this internally? It would be nice to avoid fork calls if we can
in the long run.

Cheers,

Richard




  reply	other threads:[~2023-06-23 10:18 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-06-23  9:33 [PATCH] uninative: call patchelf-uninative only when needed Martin Jansa
2023-06-23 10:18 ` Richard Purdie [this message]
2023-06-28  6:47   ` [OE-core] " Martin Jansa

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=35c96621a643bc6ef527eed83cc420eba85075ca.camel@linuxfoundation.org \
    --to=richard.purdie@linuxfoundation.org \
    --cc=Martin.Jansa@gmail.com \
    --cc=openembedded-core@lists.openembedded.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