All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Phil Blundell" <pb@pbcl.net>
To: openembedded-core@lists.openembedded.org,bkylerussell@gmail.com
Cc: wesley.lindauer@gmail.com,Kyle Russell <bkylerussell@gmail.com>
Subject: Re: [OE-core] [PATCH] lib: oe: utils: always append host gcc version to NATIVELSBSTRING
Date: Mon, 07 Jun 2021 23:01:58 +0100	[thread overview]
Message-ID: <01B7D818-661B-4A57-A3DB-C6AC0F0DD217@pbcl.net> (raw)
In-Reply-To: <20210607212558.86624-1-bkylerussell@gmail.com>

[-- Attachment #1: Type: text/plain, Size: 2603 bytes --]

Wouldn't it be easier to just force -fPIE on for those users for whom this is a problem? Or force -fPIE off for native everywhere. I'm not sure that doing something based on GCC version is obviously the right plan.

p.


On 7 June 2021 22:25:58 BST, bkylerussell@gmail.com wrote:
>By having multiple uninative feeds based on host gcc version (rather
>than a
>single uninative feed for all possible host gcc versions), we avoid a
>general
>class of problems (as first observed in the bug below) where changes in
>native
>gcc don't cause native sstate to regenerate.  Below is another example
>where
>this problem is encountered across multiple supported host distros for
>a given
>poky version.
>
>gcc 6 supports default generation of PIE, which gets enabled between
>Ubuntu
>16.04 (default gcc 5.4) and 18.04 (default gcc 7.5), both supported
>distros
>of warrior.  Consider a native package dependency chain as follows:
>
>     A
>   / | \
>  B  C  D
>
>If a complete set of native sstate for the above packages is built
>prior
>to the default PIE change, but a workstation upgrades its distro to a
>version
>that natively compiles PIE by default, the sstate hash is not currently
>tainted,
>so the newer compiler version will pull from sstate not compiled for
>PIE.
>
>For example, if a source change to C causes part of the above chain to
>rebuild
>(C -> A), then this may result in non-PIE sstate (B and D) giving link
>errors
>with A.
>
>ld: relocation R_X86_64_32 against `.rodata.str1.8' can not be used
>when making a PIE object; recompile with -fPIC
>ld: final link failed: Nonrepresentable section on output
>
>This appears to have been considered previously as an option to address
>the following bug, but appears to have been set aside only because of
>proximity to the end of a release cycle.
>
>[YOCTO #10441]
>
>Signed-off-by: Kyle Russell <bkylerussell@gmail.com>
>---
> meta/lib/oe/utils.py | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
>diff --git a/meta/lib/oe/utils.py b/meta/lib/oe/utils.py
>index a84039f585..8afe19fd99 100644
>--- a/meta/lib/oe/utils.py
>+++ b/meta/lib/oe/utils.py
>@@ -426,7 +426,7 @@ def host_gcc_version(d, taskcontextonly=False):
>bb.fatal("Can't get compiler version from %s --version output" %
>compiler)
> 
>     version = match.group(1)
>-    return "-%s" % version if version in ("4.8", "4.9") else ""
>+    return "-%s" % version
> 
> 
> def get_multilib_datastore(variant, d):
>-- 
>2.25.1

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.

[-- Attachment #2: Type: text/html, Size: 2868 bytes --]

  parent reply	other threads:[~2021-06-07 22:02 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-06-07 21:25 [PATCH] lib: oe: utils: always append host gcc version to NATIVELSBSTRING bkylerussell
2021-06-07 21:43 ` [OE-core] " Richard Purdie
2021-06-07 22:49   ` bkylerussell
2021-06-08 11:16     ` Richard Purdie
2021-06-08 16:41       ` bkylerussell
2021-06-07 22:01 ` Phil Blundell [this message]
2021-06-08  9:20   ` Andrea Adami
2021-06-08  9:48     ` Richard Purdie
2021-06-08 10:04       ` Andrea Adami

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=01B7D818-661B-4A57-A3DB-C6AC0F0DD217@pbcl.net \
    --to=pb@pbcl.net \
    --cc=bkylerussell@gmail.com \
    --cc=openembedded-core@lists.openembedded.org \
    --cc=wesley.lindauer@gmail.com \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.