arch-mips.inc: don't override TRANSLATED_TARGET_ARCH

PATCH In review Dmitry Eremin-Solenikov 2 participants 9 messages Jun 18, 2015 – Jun 19, 2015

Share & tools

Dmitry Eremin-Solenikov

author

2015-06-18 13:13 UTC #0 lore raw

PATCH 1/3 arch-mips.inc: don't override TRANSLATED_TARGET_ARCH

Currently MIPS64 N32 is broken. There is internal disagreement between TARGET_ARCH (which doesn't contain ABIEXTENSION) and TRANSLATED_TARGET_ARCH (which contains ABIEXTENSION). ABI is already encoded into the TARGET_OS. ARM tunes in the same situation override neither the TARGET_ARCH nor the TRANSLATED_TARGET_ARCH. So let's drop this override.

Signed-off-by Dmitry Eremin-Solenikov <[email protected]>

---
 meta/conf/machine/include/mips/arch-mips.inc | 4 ----
 1 file changed, 4 deletions(-)

meta/conf/machine/include/mips/arch-mips.inc +0 -4

index c41fa5e..02626d3 100644
@@ -100,7 +100,3 @@ TUNE_FEATURES_tune-mips64el-nf = "n64"
 BASE_LIB_tune-mips64el-nf = "lib64"
 MIPSPKGSFX_VARIANT_tune-mips64el-nf = "${TUNE_ARCH}"
 PACKAGE_EXTRA_ARCHS_tune-mips64el-nf = "mips64el-nf"
-
-# On mips we need to redefine this to include the ABIEXTENSION
-# we can avoid the python bit as there are no _ or - to translate
-TRANSLATED_TARGET_ARCH = "${TARGET_ARCH}${ABIEXTENSION}"

Signature · 1 line

2.1.4

Dmitry Eremin-Solenikov

author

2015-06-18 13:13 UTC #1 lore raw

PATCH 2/3 packagegroups-cross-canadian: don't override TRANSLATED_TARGET_ARCH

There is no point in overriding TRANSLATED_TARGET_ARCH in packagegroups-cross-canadian recipe. The cross-canadian class sets the PACKAGE_ARCH variable, thus allarch class (inherited through packagegroup class) doesn't change variables.

Signed-off-by Dmitry Eremin-Solenikov <[email protected]>

---
 meta/recipes-core/packagegroups/packagegroup-cross-canadian.bb | 3 ---
 1 file changed, 3 deletions(-)

meta/recipes-core/packagegroups/packagegroup-cross-canadian.bb +0 -3

index e3b1c18..34e6e2b 100644
@@ -2,9 +2,6 @@ SUMMARY = "Host SDK package for cross canadian toolchain"
 PN = "packagegroup-cross-canadian-${MACHINE}"
 LICENSE = "MIT"
 
-# Save TRANSLATED_TARGET_ARCH before allarch tramples it
-TRANSLATED_TARGET_ARCH = "${@d.getVar('TUNE_ARCH', True).replace('_', '-')}"
-
 inherit cross-canadian packagegroup
 
 PACKAGEGROUP_DISABLE_COMPLEMENTARY = "1"

Signature · 1 line

2.1.4

Dmitry Eremin-Solenikov

author

2015-06-18 13:13 UTC #2 lore raw

PATCH 3/3 cross.bbclass: override MULTIMACH_TARGET_SYS

In reply to Dmitry Eremin-Solenikov

Cross packages are built for BUILD_VENDOR/BUILD_OS, rather than TARGET_VENDOR/TARGET_OS. E.g. there is no point in hardcoding the target's LIBCEXTENSION and ABIEXTENSION into the STAMPDIR/WORKDIR variables (set using MULTIMACH_TARGET_SYS).

Signed-off-by Dmitry Eremin-Solenikov <[email protected]>

---
 meta/classes/cross.bbclass | 2 ++
 1 file changed, 2 insertions(+)

meta/classes/cross.bbclass +2 -0

index 28fd211..5ee32b2 100644
@@ -21,6 +21,8 @@ STAGING_DIR_HOST = "${STAGING_DIR}/${HOST_ARCH}${HOST_VENDOR}-${HOST_OS}"
 
 PACKAGE_ARCH = "${BUILD_ARCH}"
 
+MULTIMACH_TARGET_SYS = "${PACKAGE_ARCH}${BUILD_VENDOR}-${BUILD_OS}"
+
 export PKG_CONFIG_DIR = "${exec_prefix}/lib/pkgconfig"
 export PKG_CONFIG_SYSROOT_DIR = ""

Signature · 1 line

2.1.4

Mark Hatle

2015-06-18 13:31 UTC #3 lore raw

In reply to Dmitry Eremin-Solenikov

Quoted 6 lines · Dmitry Eremin-Solenikov

Currently MIPS64 N32 is broken. There is internal disagreement between TARGET_ARCH (which doesn't contain ABIEXTENSION) and TRANSLATED_TARGET_ARCH (which contains ABIEXTENSION). ABI is already encoded into the TARGET_OS. ARM tunes in the same situation override neither the TARGET_ARCH nor the TRANSLATED_TARGET_ARCH. So let's drop this override.

This series won't work properly, unless I'm reading something incorrectly.

You won't be able to build/install a tri-lib system after this change, as something needs to be there to differential between MIPS32 (o32), MIPS64 (n32) and MIPS64 (n64).

Currently this is done via the ABIEXTENSION value.

What is currently broken w/ MIPS64 N32? We put in a number of fixes for this problem and SDK generation in the YP 1.8 time frame. Perhaps something has changed since then or maybe the fixes were not as complete as we thought?

--Mark

Quoted 18 lines

Signed-off-by Dmitry Eremin-Solenikov <[email protected]>

---
 meta/conf/machine/include/mips/arch-mips.inc | 4 ----
 1 file changed, 4 deletions(-)

meta/conf/machine/include/mips/arch-mips.inc +0 -4

index c41fa5e..02626d3 100644
@@ -100,7 +100,3 @@ TUNE_FEATURES_tune-mips64el-nf = "n64"
 BASE_LIB_tune-mips64el-nf = "lib64"
 MIPSPKGSFX_VARIANT_tune-mips64el-nf = "${TUNE_ARCH}"
 PACKAGE_EXTRA_ARCHS_tune-mips64el-nf = "mips64el-nf"
-
-# On mips we need to redefine this to include the ABIEXTENSION
-# we can avoid the python bit as there are no _ or - to translate
-TRANSLATED_TARGET_ARCH = "${TARGET_ARCH}${ABIEXTENSION}"

Dmitry Eremin-Solenikov

author

2015-06-19 09:23 UTC #4 lore raw

In reply to Dmitry Eremin-Solenikov

Quoted 8 lines · Dmitry Eremin-Solenikov

Quoted 6 lines
Currently MIPS64 N32 is broken. There is internal disagreement between TARGET_ARCH (which doesn't contain ABIEXTENSION) and TRANSLATED_TARGET_ARCH (which contains ABIEXTENSION). ABI is already encoded into the TARGET_OS. ARM tunes in the same situation override neither the TARGET_ARCH nor the TRANSLATED_TARGET_ARCH. So let's drop this override.

Quoted 7 lines

This series won't work properly, unless I'm reading something incorrectly.
You won't be able to build/install a tri-lib system after this change, as something needs to be there to differential between MIPS32 (o32), MIPS64 (n32) and MIPS64 (n64).
Currently this is done via the ABIEXTENSION value.

Why do you need this differentiation in the TARGET_ARCH? We have TARGET_SYS (triplets) for that, don't we? And the compilers for the N64/N32 (the only thing IIRC
that is really dependent on the TARGET_ARCH) should be interchangeable, AFAIU.

Can you point me, please, how to create a tri-ABI SDK and/or image?

Quoted 4 lines

What is currently broken w/ MIPS64 N32? We put in a number of fixes for this problem and SDK generation in the YP 1.8 time frame. Perhaps something has changed since then or maybe the fixes were not as complete as we thought?

Quite simple configuration (MIPS64 N32 image) fails to build.

lumag@nexs:~/OE$ MACHINE=qemumips64n32 bitbake core-image-base
NOTE: Started PRServer with DBfile:
/home/lumag/OE/cache/prserv.sqlite3, IP: 127.0.0.1, PORT: 46391, PID:
15895
Loading cache: 100%
|########################################################################################################################|
ETA:  00:00:00
Loaded 1302 entries from dependency cache.
NOTE: Resolving any missing task queue dependencies
ERROR: Nothing RPROVIDES 'binutils-cross-canadian-mips64' (but
/home/lumag/OE/sources/openembedded-core/meta/recipes-core/packagegroups/packagegroup-cross-canadian.bb
RDEPENDS on or otherwise requires it)
NOTE: Runtime target 'binutils-cross-canadian-mips64' is unbuildable,
removing...
Missing or unbuildable dependency chain was: ['binutils-cross-canadian-mips64']
NOTE: Runtime target 'packagegroup-cross-canadian-qemumips64n32' is
unbuildable, removing...
Missing or unbuildable dependency chain was:
['packagegroup-cross-canadian-qemumips64n32',
'binutils-cross-canadian-mips64']
ERROR: Required build target 'core-image-base' has no buildable providers.
Missing or unbuildable dependency chain was: ['core-image-base',
'packagegroup-cross-canadian-qemumips64n32',
'binutils-cross-canadian-mips64']

Signature · 2 lines

With best wishes
Dmitry

Mark Hatle

2015-06-19 14:01 UTC #5 lore raw

Quoted 14 lines · Dmitry Eremin-Solenikov

Quoted 14 lines · Dmitry Eremin-Solenikov
Quoted 6 lines
Currently MIPS64 N32 is broken. There is internal disagreement between TARGET_ARCH (which doesn't contain ABIEXTENSION) and TRANSLATED_TARGET_ARCH (which contains ABIEXTENSION). ABI is already encoded into the TARGET_OS. ARM tunes in the same situation override neither the TARGET_ARCH nor the TRANSLATED_TARGET_ARCH. So let's drop this override.
This series won't work properly, unless I'm reading something incorrectly.
You won't be able to build/install a tri-lib system after this change, as something needs to be there to differential between MIPS32 (o32), MIPS64 (n32) and MIPS64 (n64).

Quoted 6 lines

Quoted 1 line
Currently this is done via the ABIEXTENSION value.
Why do you need this differentiation in the TARGET_ARCH? We have TARGET_SYS (triplets) for that, don't we? And the compilers for the N64/N32 (the only thing IIRC
that is really dependent on the TARGET_ARCH) should be interchangeable, AFAIU.

The triplet for o32 is:

mips-os-linux

The triplet to n64 is:

mips64-os-linux

The triplet to n32 is:

mips64-os-linux

thus w/o the ABI extension there is no mechanism to distinguish between n64 and n32.

Quoted 1 line

Can you point me, please, how to create a tri-ABI SDK and/or image?

Configure with a MIPS64 capable machine (yes qemumips64 is adequate). Then add the following to your local.conf:

require conf/multilib.conf
DEFAULTTUNE = "mips32r2"

MULTILIBS = "multilib:lib32 multilib:lib64" DEFAULTTUNE_virtclass-multilib-lib32 = "mips64-n32" DEFAULTTUNE_virtclass-multilib-lib64 = "mips64"

This will set the default ABI to 'o32', with optional n32 and n64 support. (You can switch around the defaulttune values to change which is default and which is optional. A common config is n32 default, o32 / n64 optional.)

Quoted 8 lines

Quoted 4 lines
What is currently broken w/ MIPS64 N32? We put in a number of fixes for this problem and SDK generation in the YP 1.8 time frame. Perhaps something has changed since then or maybe the fixes were not as complete as we thought?
Quite simple configuration (MIPS64 N32 image) fails to build.

Quoted 14 lines

lumag@nexs:~/OE$ MACHINE=qemumips64n32 bitbake core-image-base
NOTE: Started PRServer with DBfile:
/home/lumag/OE/cache/prserv.sqlite3, IP: 127.0.0.1, PORT: 46391, PID:
15895
Loading cache: 100%
|########################################################################################################################|
ETA:  00:00:00
Loaded 1302 entries from dependency cache.
NOTE: Resolving any missing task queue dependencies
ERROR: Nothing RPROVIDES 'binutils-cross-canadian-mips64' (but
/home/lumag/OE/sources/openembedded-core/meta/recipes-core/packagegroups/packagegroup-cross-canadian.bb
RDEPENDS on or otherwise requires it)
NOTE: Runtime target 'binutils-cross-canadian-mips64' is unbuildable,
removing...

Looks to me that when binutils was upgraded, the rename of the arch component broke in some way. The arch renaming used by the cross-canadian toolchain components SHOULD have changed things to me "mips64-n32" in the n32 case. This is the purpose of the ABIEXTENSION being added to the 'TRANSLATED_TARGET_ARCH' in arch-mips.conf. See commit: 0bcc01121e928d0be7a0550e500425852c63cf98 for additional details.

(The commit msg includes the configuration listed above as well.)

--Mark

Quoted 14 lines

Missing or unbuildable dependency chain was: ['binutils-cross-canadian-mips64']
NOTE: Runtime target 'packagegroup-cross-canadian-qemumips64n32' is unbuildable, removing...
Missing or unbuildable dependency chain was:
['packagegroup-cross-canadian-qemumips64n32', 'binutils-cross-canadian-mips64']
ERROR: Required build target 'core-image-base' has no buildable providers. Missing or unbuildable dependency chain was: ['core-image-base', 'packagegroup-cross-canadian-qemumips64n32', 'binutils-cross-canadian-mips64']

Dmitry Eremin-Solenikov

author

2015-06-19 16:49 UTC #6 lore raw

Hello,

2015-06-19 17:01 GMT+03:00 Mark Hatle <[email protected]>:

Quoted 26 lines · Dmitry Eremin-Solenikov

Quoted 14 lines
Quoted 14 lines · Dmitry Eremin-Solenikov
Quoted 6 lines
Currently MIPS64 N32 is broken. There is internal disagreement between TARGET_ARCH (which doesn't contain ABIEXTENSION) and TRANSLATED_TARGET_ARCH (which contains ABIEXTENSION). ABI is already encoded into the TARGET_OS. ARM tunes in the same situation override neither the TARGET_ARCH nor the TRANSLATED_TARGET_ARCH. So let's drop this override.
This series won't work properly, unless I'm reading something incorrectly.
You won't be able to build/install a tri-lib system after this change, as something needs to be there to differential between MIPS32 (o32), MIPS64 (n32) and MIPS64 (n64).
Quoted 6 lines
Quoted 1 line
Currently this is done via the ABIEXTENSION value.
Why do you need this differentiation in the TARGET_ARCH? We have TARGET_SYS (triplets) for that, don't we? And the compilers for the N64/N32 (the only thing IIRC
that is really dependent on the TARGET_ARCH) should be interchangeable, AFAIU.
The triplet for o32 is:
mips-os-linux

Quoted 7 lines

The triplet to n64 is:
mips64-os-linux
The triplet to n32 is:
mips64-os-linux

No. It is mips64-oe-linux-gnun32! Even with my patches.

Quoted 1 line

thus w/o the ABI extension there is no mechanism to distinguish between n64 and n32.

See, the arch is the same (MIPS64), it should not encode the ABI. The multiplet differs
(mips64-oe-linux vs. mips64-oe-linux-gnun32) and this also looks correct.

Quoted 9 lines

Quoted 2 lines
Can you point me, please, how to create a tri-ABI SDK and/or image?
Configure with a MIPS64 capable machine (yes qemumips64 is adequate). Then add the following to your local.conf:
require conf/multilib.conf
DEFAULTTUNE = "mips32r2"

Quoted 8 lines

MULTILIBS = "multilib:lib32 multilib:lib64" DEFAULTTUNE_virtclass-multilib-lib32 = "mips64-n32" DEFAULTTUNE_virtclass-multilib-lib64 = "mips64"
This will set the default ABI to 'o32', with optional n32 and n64 support. (You can switch around the defaulttune values to change which is default and which is optional. A common config is n32 default, o32 / n64 optional.)

I'll try with this with my patches.

Quoted 32 lines

Quoted 9 lines
Quoted 5 lines
What is currently broken w/ MIPS64 N32? We put in a number of fixes for this problem and SDK generation in the YP 1.8 time frame. Perhaps something has changed since then or maybe the fixes were not as complete as we thought?
Quite simple configuration (MIPS64 N32 image) fails to build.
Quoted 14 lines
lumag@nexs:~/OE$ MACHINE=qemumips64n32 bitbake core-image-base
NOTE: Started PRServer with DBfile:
/home/lumag/OE/cache/prserv.sqlite3, IP: 127.0.0.1, PORT: 46391, PID:
15895
Loading cache: 100%
|########################################################################################################################|
ETA:  00:00:00
Loaded 1302 entries from dependency cache.
NOTE: Resolving any missing task queue dependencies
ERROR: Nothing RPROVIDES 'binutils-cross-canadian-mips64' (but
/home/lumag/OE/sources/openembedded-core/meta/recipes-core/packagegroups/packagegroup-cross-canadian.bb
RDEPENDS on or otherwise requires it)
NOTE: Runtime target 'binutils-cross-canadian-mips64' is unbuildable,
removing...
Looks to me that when binutils was upgraded, the rename of the arch component broke in some way. The arch renaming used by the cross-canadian toolchain components SHOULD have changed things to me "mips64-n32" in the n32 case. This is the purpose of the ABIEXTENSION being added to the 'TRANSLATED_TARGET_ARCH' in arch-mips.conf. See commit: 0bcc01121e928d0be7a0550e500425852c63cf98 for additional details.
(The commit msg includes the configuration listed above as well.)

Signature · 2 lines

With best wishes
Dmitry

Dmitry Eremin-Solenikov

author

2015-06-19 17:47 UTC #7 lore raw

In reply to Mark Hatle

Hello,

2015-06-19 17:01 GMT+03:00 Mark Hatle <[email protected]>:

Quoted 44 lines · Dmitry Eremin-Solenikov

Quoted 14 lines
Quoted 14 lines · Dmitry Eremin-Solenikov
Quoted 6 lines
Currently MIPS64 N32 is broken. There is internal disagreement between TARGET_ARCH (which doesn't contain ABIEXTENSION) and TRANSLATED_TARGET_ARCH (which contains ABIEXTENSION). ABI is already encoded into the TARGET_OS. ARM tunes in the same situation override neither the TARGET_ARCH nor the TRANSLATED_TARGET_ARCH. So let's drop this override.
This series won't work properly, unless I'm reading something incorrectly.
You won't be able to build/install a tri-lib system after this change, as something needs to be there to differential between MIPS32 (o32), MIPS64 (n32) and MIPS64 (n64).
Quoted 6 lines
Quoted 1 line
Currently this is done via the ABIEXTENSION value.
Why do you need this differentiation in the TARGET_ARCH? We have TARGET_SYS (triplets) for that, don't we? And the compilers for the N64/N32 (the only thing IIRC
that is really dependent on the TARGET_ARCH) should be interchangeable, AFAIU.
The triplet for o32 is:
mips-os-linux
The triplet to n64 is:
mips64-os-linux
The triplet to n32 is:
mips64-os-linux
thus w/o the ABI extension there is no mechanism to distinguish between n64 and n32.
Quoted 1 line
Can you point me, please, how to create a tri-ABI SDK and/or image?
Configure with a MIPS64 capable machine (yes qemumips64 is adequate). Then add the following to your local.conf:
require conf/multilib.conf
DEFAULTTUNE = "mips32r2"

Quoted 8 lines

MULTILIBS = "multilib:lib32 multilib:lib64" DEFAULTTUNE_virtclass-multilib-lib32 = "mips64-n32" DEFAULTTUNE_virtclass-multilib-lib64 = "mips64"
This will set the default ABI to 'o32', with optional n32 and n64 support. (You can switch around the defaulttune values to change which is default and which is optional. A common config is n32 default, o32 / n64 optional.)

I tried adding these settings to a special machine config (but there should be no
difference with adding them to local.conf) and got a lot of errors from QA on linux-yocto (because of 32 vs 64 bitness missmatch on kernel objects). Are you sure that this config works out of box for you?

Signature · 2 lines

With best wishes
Dmitry

Dmitry Eremin-Solenikov

author

2015-06-19 22:40 UTC #8 lore raw

2015-06-19 20:47 GMT+03:00 Dmitry Eremin-Solenikov <[email protected]>:

Quoted 57 lines

Hello,
2015-06-19 17:01 GMT+03:00 Mark Hatle <[email protected]>:
Quoted 44 lines · Dmitry Eremin-Solenikov
Quoted 14 lines
Quoted 14 lines · Dmitry Eremin-Solenikov
Quoted 6 lines
Currently MIPS64 N32 is broken. There is internal disagreement between TARGET_ARCH (which doesn't contain ABIEXTENSION) and TRANSLATED_TARGET_ARCH (which contains ABIEXTENSION). ABI is already encoded into the TARGET_OS. ARM tunes in the same situation override neither the TARGET_ARCH nor the TRANSLATED_TARGET_ARCH. So let's drop this override.
This series won't work properly, unless I'm reading something incorrectly.
You won't be able to build/install a tri-lib system after this change, as something needs to be there to differential between MIPS32 (o32), MIPS64 (n32) and MIPS64 (n64).
Quoted 6 lines
Quoted 1 line
Currently this is done via the ABIEXTENSION value.
Why do you need this differentiation in the TARGET_ARCH? We have TARGET_SYS (triplets) for that, don't we? And the compilers for the N64/N32 (the only thing IIRC
that is really dependent on the TARGET_ARCH) should be interchangeable, AFAIU.
The triplet for o32 is:
mips-os-linux
The triplet to n64 is:
mips64-os-linux
The triplet to n32 is:
mips64-os-linux
thus w/o the ABI extension there is no mechanism to distinguish between n64 and n32.
Quoted 1 line
Can you point me, please, how to create a tri-ABI SDK and/or image?
Configure with a MIPS64 capable machine (yes qemumips64 is adequate). Then add the following to your local.conf:
require conf/multilib.conf
DEFAULTTUNE = "mips32r2"
Quoted 8 lines
MULTILIBS = "multilib:lib32 multilib:lib64" DEFAULTTUNE_virtclass-multilib-lib32 = "mips64-n32" DEFAULTTUNE_virtclass-multilib-lib64 = "mips64"
This will set the default ABI to 'o32', with optional n32 and n64 support. (You can switch around the defaulttune values to change which is default and which is optional. A common config is n32 default, o32 / n64 optional.)

Quoted 5 lines

I tried adding these settings to a special machine config (but there should be no
difference with adding them to local.conf) and got a lot of errors from QA on linux-yocto (because of 32 vs 64 bitness missmatch on kernel objects). Are you sure that this config works out of box for you?

Got the tri-ABI image built. Had to change default to N32, fix the glibc recipe not to override the TUNE_CCARGS, etc. Here is a summary:

1) My patches do not break building multilib images/SDK.
2) They are required to build images, defaulting to N32 ABI
3) Building tri-lib images does not work out of box anyway, thanks to glibc (I'll send a patch).
4) Multilib SDK for MIPS build, but the build is quite questionable anyway (see below).

Thus I'd ask for my patches to be merged.

WARNING: gcc multilib setup is not supported for TARGET_ARCH=mips64

WARNING: gcc multilib setup is not
supported for TARGET_ARCH=mips64
WARNING: gcc multilib setup is not supported for TARGET_ARCH=mips64
WARNING: QA Issue: gcc-cross-canadian-mips64: Files/directories were
installed but not shipped in any package:
/usr/local/oecore-x86_64/sysroots/x86_64-oesdk-linux/usr/lib/lib /usr/local/oecore-x86_64/sysroots/x86_64-oesdk-linux/usr/lib/mips64-oemllib64-linux/gcc/mips64-oemllib64-linux/5.1.0/plugin/libcc1plugin.so.0.0.0 /usr/local/oecore-x86_64/sysroots/x86_64-oesdk-linux/usr/lib/mips64-oemllib64-linux/gcc/mips64-oemllib64-linux/5.1.0/plugin/libcc1plugin.so.0 /usr/local/oecore-x86_64/sysroots/x86_64-oesdk-linux/usr/lib/mips64-oemllib64-linux/gcc/mips64-oemllib64-linux/5.1.0/plugin/libcc1plugin.la /usr/local/oecore-x86_64/sysroots/x86_64-oesdk-linux/usr/lib/mips64-oemllib64-linux/gcc/mips64-oemllib64-linux/5.1.0/plugin/libcc1plugin.so /usr/local/oecore-x86_64/sysroots/x86_64-oesdk-linux/usr/lib/mips64-oemllib64-linux/gcc/mips64-oemllib64-linux/5.1.0/plugin/.debug /usr/local/oecore-x86_64/sysroots/x86_64-oesdk-linux/usr/lib/mips64-oemllib64-linux/gcc/mips64-oemllib64-linux/5.1.0/plugin/.debug/libcc1plugin.so.0.0.0 /usr/local/oecore-x86_64/sysroots/x86_64-oesdk-linux/usr/lib/lib/libcc1.la /usr/local/oecore-x86_64/sysroots/x86_64-oesdk-linux/usr/lib/lib/libcc1.so /usr/local/oecore-x86_64/sysroots/x86_64-oesdk-linux/usr/lib/lib/libcc1.so.0.0.0 /usr/local/oecore-x86_64/sysroots/x86_64-oesdk-linux/usr/lib/lib/libcc1.so.0 /usr/local/oecore-x86_64/sysroots/x86_64-oesdk-linux/usr/lib/lib/.debug /usr/local/oecore-x86_64/sysroots/x86_64-oesdk-linux/usr/lib/lib/.debug/libcc1.so.0.0.0
Please set FILES such that these items are packaged. Alternatively if
they are unneeded, avoid installing them or delete them within
do_install. [installed-vs-shipped]
WARNING: QA Issue: gcc-cross-canadian-mips: Files/directories were
installed but not shipped in any package:
/usr/local/oecore-x86_64/sysroots/x86_64-oesdk-linux/usr/lib/lib /usr/local/oecore-x86_64/sysroots/x86_64-oesdk-linux/usr/lib/lib/libcc1.la /usr/local/oecore-x86_64/sysroots/x86_64-oesdk-linux/usr/lib/lib/libcc1.so /usr/local/oecore-x86_64/sysroots/x86_64-oesdk-linux/usr/lib/lib/libcc1.so.0.0.0 /usr/local/oecore-x86_64/sysroots/x86_64-oesdk-linux/usr/lib/lib/libcc1.so.0 /usr/local/oecore-x86_64/sysroots/x86_64-oesdk-linux/usr/lib/lib/.debug /usr/local/oecore-x86_64/sysroots/x86_64-oesdk-linux/usr/lib/lib/.debug/libcc1.so.0.0.0 /usr/local/oecore-x86_64/sysroots/x86_64-oesdk-linux/usr/lib/mips-oemllib32-linux/gcc/mips-oemllib32-linux/5.1.0/plugin/libcc1plugin.so.0.0.0 /usr/local/oecore-x86_64/sysroots/x86_64-oesdk-linux/usr/lib/mips-oemllib32-linux/gcc/mips-oemllib32-linux/5.1.0/plugin/libcc1plugin.so.0 /usr/local/oecore-x86_64/sysroots/x86_64-oesdk-linux/usr/lib/mips-oemllib32-linux/gcc/mips-oemllib32-linux/5.1.0/plugin/libcc1plugin.la /usr/local/oecore-x86_64/sysroots/x86_64-oesdk-linux/usr/lib/mips-oemllib32-linux/gcc/mips-oemllib32-linux/5.1.0/plugin/libcc1plugin.so /usr/local/oecore-x86_64/sysroots/x86_64-oesdk-linux/usr/lib/mips-oemllib32-linux/gcc/mips-oemllib32-linux/5.1.0/plugin/.debug /usr/local/oecore-x86_64/sysroots/x86_64-oesdk-linux/usr/lib/mips-oemllib32-linux/gcc/mips-oemllib32-linux/5.1.0/plugin/.debug/libcc1plugin.so.0.0.0

Signature · 2 lines

With best wishes
Dmitry