* [PATCH 1/1] libgcc-common.inc: Fix symbol link to mutilib directories
@ 2017-01-23 3:48 Yuanjie Huang
2017-01-23 3:53 ` ✗ patchtest: failure for " Patchwork
` (2 more replies)
0 siblings, 3 replies; 6+ messages in thread
From: Yuanjie Huang @ 2017-01-23 3:48 UTC (permalink / raw)
To: openembedded-core
From: Yuanjie Huang <yuanjie.huang@windriver.com>
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 | 15 +++++++--------
1 file changed, 7 insertions(+), 8 deletions(-)
diff --git a/meta/recipes-devtools/gcc/libgcc-common.inc b/meta/recipes-devtools/gcc/libgcc-common.inc
index a8a3f0d..69eeb26 100644
--- a/meta/recipes-devtools/gcc/libgcc-common.inc
+++ b/meta/recipes-devtools/gcc/libgcc-common.inc
@@ -106,20 +106,19 @@ 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 = bb.data.createCopy(d)
+ overrides = localdata.getVar("OVERRIDES", False) + ":virtclass-multilib-" + ml
+ localdata.setVar("OVERRIDES", overrides)
+ localdata.setVar("MLPREFIX", ml + "-")
+ bb.data.update_data(localdata)
+ ml_target_sys = localdata.getVar('TARGET_SYS', True) or ''
src = '../../../' + tune_baselib + '/' + \
- tune_arch + d.getVar('TARGET_VENDOR', True) + 'ml' + ml + \
- '-' + d.getVar('TARGET_OS', True) + libcextension + '/' + binv + '/'
+ ml_target_sys + '/' + binv + '/'
dest = d.getVar('D', True) + d.getVar('libdir', True) + '/' + \
d.getVar('TARGET_SYS', True) + '/' + binv + '/' + tune_bitness
--
2.9.3
^ permalink raw reply related [flat|nested] 6+ messages in thread
* ✗ patchtest: failure for libgcc-common.inc: Fix symbol link to mutilib directories
2017-01-23 3:48 [PATCH 1/1] libgcc-common.inc: Fix symbol link to mutilib directories Yuanjie Huang
@ 2017-01-23 3:53 ` Patchwork
2017-01-23 4:11 ` [PATCH v2] " Yuanjie Huang
2017-01-23 8:15 ` [PATCH 1/1] " Richard Purdie
2 siblings, 0 replies; 6+ messages in thread
From: Patchwork @ 2017-01-23 3:53 UTC (permalink / raw)
To: Yuanjie Huang; +Cc: openembedded-core
== Series Details ==
Series: libgcc-common.inc: Fix symbol link to mutilib directories
Revision: 1
URL : https://patchwork.openembedded.org/series/4894/
State : failure
== Summary ==
Thank you for submitting this patch series to OpenEmbedded Core. This is
an automated response. Several tests have been executed on the proposed
series by patchtest resulting in the following failures:
* Issue Series does not apply on top of target branch [test_series_merge_on_head]
Suggested fix Rebase your series on top of targeted branch
Targeted branch master (currently at 5ecdab6c25)
If you believe any of these test results are incorrect, please reply to the
mailing list (openembedded-core@lists.openembedded.org) raising your concerns.
Otherwise we would appreciate you correcting the issues and submitting a new
version of the patchset if applicable. Please ensure you add/increment the
version number when sending the new version (i.e. [PATCH] -> [PATCH v2] ->
[PATCH v3] -> ...).
---
Test framework: http://git.yoctoproject.org/cgit/cgit.cgi/patchtest
Test suite: http://git.yoctoproject.org/cgit/cgit.cgi/patchtest-oe
^ permalink raw reply [flat|nested] 6+ messages in thread
* [PATCH v2] libgcc-common.inc: Fix symbol link to mutilib directories
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 ` Yuanjie Huang
2017-01-23 8:15 ` [PATCH 1/1] " Richard Purdie
2 siblings, 0 replies; 6+ messages in thread
From: Yuanjie Huang @ 2017-01-23 4:11 UTC (permalink / raw)
To: openembedded-core
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 | 15 +++++++--------
1 file changed, 7 insertions(+), 8 deletions(-)
diff --git a/meta/recipes-devtools/gcc/libgcc-common.inc b/meta/recipes-devtools/gcc/libgcc-common.inc
index 7a3b410..4ccdfb9 100644
--- a/meta/recipes-devtools/gcc/libgcc-common.inc
+++ b/meta/recipes-devtools/gcc/libgcc-common.inc
@@ -106,20 +106,19 @@ 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 = bb.data.createCopy(d)
+ overrides = localdata.getVar("OVERRIDES", False) + ":virtclass-multilib-" + ml
+ localdata.setVar("OVERRIDES", overrides)
+ localdata.setVar("MLPREFIX", ml + "-")
+ bb.data.update_data(localdata)
+ 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
--
2.9.3
^ permalink raw reply related [flat|nested] 6+ messages in thread
* Re: [PATCH 1/1] libgcc-common.inc: Fix symbol link to mutilib directories
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 ` Richard Purdie
2017-01-23 8:29 ` [PATCH V3] " Yuanjie Huang
2 siblings, 1 reply; 6+ messages in thread
From: Richard Purdie @ 2017-01-23 8:15 UTC (permalink / raw)
To: Yuanjie Huang, openembedded-core
Hi,
On Mon, 2017-01-23 at 11:48 +0800, Yuanjie Huang wrote:
> From: Yuanjie Huang <yuanjie.huang@windriver.com>
>
> 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 | 15 +++++++--------
> 1 file changed, 7 insertions(+), 8 deletions(-)
>
> diff --git a/meta/recipes-devtools/gcc/libgcc-common.inc
> b/meta/recipes-devtools/gcc/libgcc-common.inc
> index a8a3f0d..69eeb26 100644
> --- a/meta/recipes-devtools/gcc/libgcc-common.inc
> +++ b/meta/recipes-devtools/gcc/libgcc-common.inc
> @@ -106,20 +106,19 @@ 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 = bb.data.createCopy(d)
> + overrides = localdata.getVar("OVERRIDES", False) +
> ":virtclass-multilib-" + ml
> + localdata.setVar("OVERRIDES", overrides)
> + localdata.setVar("MLPREFIX", ml + "-")
> + bb.data.update_data(localdata)
> + ml_target_sys = localdata.getVar('TARGET_SYS', True) or ''
>
Please take advantage of:
http://git.yoctoproject.org/cgit.cgi/poky/commit/?id=a49ee524a933b433ea9c2e2be1bbf24909fcde77
Cheers,
Richard
^ permalink raw reply [flat|nested] 6+ messages in thread
* [PATCH V3] libgcc-common.inc: Fix symbol link to mutilib directories
2017-01-23 8:15 ` [PATCH 1/1] " Richard Purdie
@ 2017-01-23 8:29 ` Yuanjie Huang
2017-01-23 12:22 ` Richard Purdie
0 siblings, 1 reply; 6+ messages in thread
From: Yuanjie Huang @ 2017-01-23 8:29 UTC (permalink / raw)
To: openembedded-core
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
--
2.9.3
^ permalink raw reply related [flat|nested] 6+ messages in thread
* Re: [PATCH V3] libgcc-common.inc: Fix symbol link to mutilib directories
2017-01-23 8:29 ` [PATCH V3] " Yuanjie Huang
@ 2017-01-23 12:22 ` Richard Purdie
0 siblings, 0 replies; 6+ messages in thread
From: Richard Purdie @ 2017-01-23 12:22 UTC (permalink / raw)
To: Yuanjie Huang, openembedded-core
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
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2017-01-23 12:22 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
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 is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox