Re: [OE-core] [PATCH 1/3] arch-mips.inc: don't override TRANSLATED_TARGET_ARCH
2015-06-19 20:47 GMT+03:00 Dmitry Eremin-Solenikov dbarysh...@gmail.com: Hello, 2015-06-19 17:01 GMT+03:00 Mark Hatle mark.ha...@windriver.com: On 6/19/15 4:23 AM, Dmitry Eremin-Solenikov wrote: On 6/18/15 8:13 AM, Dmitry Eremin-Solenikov wrote: 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. 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. 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.) 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
Re: [OE-core] [PATCH 1/3] arch-mips.inc: don't override TRANSLATED_TARGET_ARCH
On 6/19/15 4:23 AM, Dmitry Eremin-Solenikov wrote: On 6/18/15 8:13 AM, Dmitry Eremin-Solenikov wrote: 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. 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. 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.) 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... 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 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'] -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 1/3] arch-mips.inc: don't override TRANSLATED_TARGET_ARCH
On 6/18/15 8:13 AM, Dmitry Eremin-Solenikov wrote: 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. 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? 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'] -- With best wishes Dmitry -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 1/3] arch-mips.inc: don't override TRANSLATED_TARGET_ARCH
Hello, 2015-06-19 17:01 GMT+03:00 Mark Hatle mark.ha...@windriver.com: On 6/19/15 4:23 AM, Dmitry Eremin-Solenikov wrote: On 6/18/15 8:13 AM, Dmitry Eremin-Solenikov wrote: 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. 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 No. It is mips64-oe-linux-gnun32! Even with my patches. 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. 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.) I'll try with this with my patches. 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... 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.) -- With best wishes Dmitry -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 1/3] arch-mips.inc: don't override TRANSLATED_TARGET_ARCH
Hello, 2015-06-19 17:01 GMT+03:00 Mark Hatle mark.ha...@windriver.com: On 6/19/15 4:23 AM, Dmitry Eremin-Solenikov wrote: On 6/18/15 8:13 AM, Dmitry Eremin-Solenikov wrote: 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. 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. 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.) 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? -- With best wishes Dmitry -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 1/3] arch-mips.inc: don't override TRANSLATED_TARGET_ARCH
On 6/18/15 8:13 AM, Dmitry Eremin-Solenikov wrote:
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
Signed-off-by: Dmitry Eremin-Solenikov dbarysh...@gmail.com
---
meta/conf/machine/include/mips/arch-mips.inc | 4
1 file changed, 4 deletions(-)
diff --git a/meta/conf/machine/include/mips/arch-mips.inc
b/meta/conf/machine/include/mips/arch-mips.inc
index c41fa5e..02626d3 100644
--- a/meta/conf/machine/include/mips/arch-mips.inc
+++ b/meta/conf/machine/include/mips/arch-mips.inc
@@ -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}
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [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 dbarysh...@gmail.com
---
meta/conf/machine/include/mips/arch-mips.inc | 4
1 file changed, 4 deletions(-)
diff --git a/meta/conf/machine/include/mips/arch-mips.inc
b/meta/conf/machine/include/mips/arch-mips.inc
index c41fa5e..02626d3 100644
--- a/meta/conf/machine/include/mips/arch-mips.inc
+++ b/meta/conf/machine/include/mips/arch-mips.inc
@@ -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}
--
2.1.4
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
