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