[OE-core] [PATCH 0/4] Fix builds for MIPS64 N32

[Dmitry Eremin-Solenikov]

2015-07-31 13:59 GMT+03:00 Richard Purdie <richard.purdie at linuxfoundation.org>:
> On Wed, 2015-07-29 at 18:00 +0300, Dmitry Eremin-Solenikov wrote:
>> > Recent check-ins have changed some things.  The compile side was working for a
>> > while, but not the compilation side (using it).
>> >
>> > I've been working with RP on IRC, and he's come up with some additional patches.
>> >  (including this set of 4..)
>> >
>> > So I think the set is fine, it's up to the other pieces that need to mesh with
>> > this to produce the working SDK.
>>
>> Ok. So what would be the plan then? If you need any additional tests
>> from my side,
>> I can provide them.
>
> Sorry for the delays on this. I found several issues and ended up with
> some quite subtle gcc changes to make all this work. I've put both our
> changes into master-next. The local.conf testing setup I've been using
> is:
>
> MACHINE = "qemumips64"
> require conf/multilib.conf
> DEFAULTTUNE = "mips64-n32"
> MULTILIBS = "multilib:lib64 multilib:lib32"
> DEFAULTTUNE_virtclass-multilib-lib64 = "mips64"
> DEFAULTTUNE_virtclass-multilib-lib32 = "mips32r2"
>
> then the build/test commands:
>
> bitbake core-image-minimal -c populate_sdk
> bitbake core-image-minimal -c testsdk
>
> The nice thing is the latter automated test part now passes for this
> configuration (and its tests all three multilibs).
>
> What remains is to run these changes through the autobuilder and make
> sure nothing else breaks as a result of this patchset. I'm about to do
> some business travel which means my ability to debug any further issues
> will be limited, compiling toolchains on the laptop isn't realistic. I
> may therefore need help in ironing out any further wrinkles or we'll
> have to wait until I get back in a couple of weeks.

I should be able to test your changes in a more or less timely manner,
so feel free to ping me if the need arises.

-- 
With best wishes
Dmitry