Openembedded Core Discussions
 help / color / mirror / Atom feed
From: Richard Purdie <richard.purdie@linuxfoundation.org>
To: Yuanjie Huang <yuanjie.huang@windriver.com>,
	openembedded-core@lists.openembedded.org
Subject: Re: [PATCH V3] libgcc-common.inc: Fix symbol link to mutilib directories
Date: Mon, 23 Jan 2017 12:22:09 +0000	[thread overview]
Message-ID: <1485174129.30673.14.camel@linuxfoundation.org> (raw)
In-Reply-To: <20170123082922.243238-1-yuanjie.huang@windriver.com>

On Mon, 2017-01-23 at 00:29 -0800, Yuanjie Huang wrote:
> The multilib symbol links are created for gcc to locate libgcc files.
> Its source path contains TARGET_SYS of multilib libgcc. However, a
> multilib's TARGET_SYS is not generated correctly all the time now.
> For example,
> 
>   MACHINE = "qemumips64"
>   DEFAULTTUNE = "mips64-n32"
>   MULTILIBS = "multilib:lib64"
>   DEFAULTTUNE_virtclass-multilib-lib64 = "mips64"
> 
> In N32 libgcc, the symbol link for N64 is created as:
> 
>   64 -> ../../../lib64/mips64-wrsmllib64-linux-gnun32/5.2.0/
> 
> while it should be:
> 
>   64 -> ../../../lib64/mips64-wrsmllib64-linux/5.2.0/
> 
> This issue sometimes won't break compiler, since gcc also searches
> paths
> calculated with OS multilib directories beside multilib directories .
> 
> This patch resolve the problem by reading TARGET_SYS from a localdata
> environment with proper multilib overrides.
> 
> Signed-off-by: Yuanjie Huang <yuanjie.huang@windriver.com>
> ---
>  meta/recipes-devtools/gcc/libgcc-common.inc | 11 +++--------
>  1 file changed, 3 insertions(+), 8 deletions(-)
> 
> diff --git a/meta/recipes-devtools/gcc/libgcc-common.inc
> b/meta/recipes-devtools/gcc/libgcc-common.inc
> index 7a3b410..7198664 100644
> --- a/meta/recipes-devtools/gcc/libgcc-common.inc
> +++ b/meta/recipes-devtools/gcc/libgcc-common.inc
> @@ -106,20 +106,15 @@ fakeroot python do_multilib_install() {
>              bb.warn("Tune %s doesn't have a baselib set.
> Skipping..." % tune)
>              continue
>  
> -        tune_arch = tune_parameters['arch']
>          tune_bitness = tune_baselib.replace('lib', '')
>          if not tune_bitness:
>              tune_bitness = '32' # /lib => 32bit lib
>  
> -        tune_abiextension = tune_parameters['abiextension']
> -        if tune_abiextension:
> -            libcextension = '-gnu' + tune_abiextension
> -        else:
> -            libcextension = ''
> +        localdata = get_multilib_datastore(ml, d)
> +        ml_target_sys = localdata.getVar('TARGET_SYS') or ''
>  
>          src = '../../../' + tune_baselib + '/' + \
> -            tune_arch + d.getVar('TARGET_VENDOR') + 'ml' + ml + \
> -            '-' + d.getVar('TARGET_OS') + libcextension +  '/' +
> binv + '/'
> +            ml_target_sys + '/' + binv + '/'
>  
>          dest = d.getVar('D') + d.getVar('libdir') + '/' + \
>              d.getVar('TARGET_SYS') + '/' + binv + '/' + tune_bitness

This looks better, thanks. Looking at the function a bit more, I
suspect we should probably do something like:

tune_bitness = (localdata.getVar('baselib') or '').replace('lib', '')

and then drop the get_tune_parameters call entirely.

Cheers,

Richard



      reply	other threads:[~2017-01-23 12:22 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-01-23  3:48 [PATCH 1/1] libgcc-common.inc: Fix symbol link to mutilib directories Yuanjie Huang
2017-01-23  3:53 ` ✗ patchtest: failure for " Patchwork
2017-01-23  4:11 ` [PATCH v2] " Yuanjie Huang
2017-01-23  8:15 ` [PATCH 1/1] " Richard Purdie
2017-01-23  8:29   ` [PATCH V3] " Yuanjie Huang
2017-01-23 12:22     ` Richard Purdie [this message]

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=1485174129.30673.14.camel@linuxfoundation.org \
    --to=richard.purdie@linuxfoundation.org \
    --cc=openembedded-core@lists.openembedded.org \
    --cc=yuanjie.huang@windriver.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox