[OE-core] [PATCH 1/4] u-boot: Update to 2016.09.01 release

[Khem Raj]

> On Oct 27, 2016, at 5:18 PM, Marek Vasut <marex at denx.de> wrote:
> 
> On 10/27/2016 01:44 PM, Stefan Müller-Klieser wrote:
>> On 25.10.2016 21:24, Marek Vasut wrote:
>>> On 10/25/2016 08:32 PM, Denys Dmytriyenko wrote:
>>>> On Sat, Oct 22, 2016 at 10:32:12PM +0200, Marek Vasut wrote:
>>>>> On 10/21/2016 09:47 AM, Burton, Ross wrote:
>>>>> 
>>>>> Hi!
>>>>> 
>>>>>> On 20 October 2016 at 14:35, Marek Vasut <marex at denx.de
>>>>>> <mailto:marex at denx.de>> wrote:
>>>>>> 
>>>>>>    Upgrade U-Boot to the latest version.
>>>>>> 
>>>>>> 
>>>>>> As usual, u-boot-mkimage broke again:
>>>>> 
>>>>> That's weird, I successfully built it for nios2 during my tests.
>>>>> Can you tell me how I can replicate the issue , so I can test for it to
>>>>> prevent regression and roll out a patch ?
>>>> 
>>>> Marek, Ross,
>>>> 
>>>> Any progress on this? Need any help testing?
>>>> 
>>> Yeah, how do you replicate this issue ?
>>> 
>> Hi!
> 
> Hi!
> 
>> I am just looking at a similar problem and want to jump into the discussion.
>> As Ross said, the problem is to not respect host/target -- cc/cflags/ldflags.
>> So to replicate the issue, you can use a bare minimum build host with no
>> cross toolchain installed, and I guess all targets will fail to build.
> 
> Well both ARM and nios2 builds for me, so I wonder what sort of stupid
> thing am I doing.


perhaps, its manifesting when toolchain is used from sstate, moreover the sstate
comes from a mirror which is populated from a workspace which has different
build time paths, which means its encoding a different default sysroot into
toolchain. So unless you add TOOLCHAIN_OPTIONS to the CC and its ilk
you will have issues.

May be you can reproduce it by

1. build first time ./oe-init-build-env /path/to/build1
2. Now set another builddir may be using ./oe-init-build-env /path/to/build2
3. Add a SSTATE_MIRROR pointing to sstate from first builddir add below to local.conf

SSTATE_MIRRORS ?= "\
file://.* file:///path/to/build1/sstate-cache/PATH”

4. bitbake <package>
5. bitbake -ccleansstate <package>
6. bitbake package



> 
>> As this has been broken so many times, I want to discuss some possible fixes:
>> In the top level Makefile we have:
>> HOSTCC = cc
>> HOSTCFLAGS = ...
>> The problem is, you cannot properly override those variables, as they get used
>> a lot to do different things, e.g. in tools/Makefile we have (for cross tools
>> target) HOSTCC = $(CC) and for HOSTCFLAGS we have appends for configuration.
>> Thats why we have the current workaround with a squashed override. I see many
>> possible solutions and would like to hear your opinion:
>> 1. Make top level Makefile HOST assignments conditional "?="
>>   - easy
>>   - will probably not be accepted upstream
> 
> Why ?
> 
>> 2. add "override" to appends in sublevel Makefiles
>>   - adds complexity/one level of override hierarchy
>> 3. Don't use appends for those variables (like in the kernel Makefile), overrides
>>   in the recipe
>>   - clean
>>   - quite some rework in uboot
> 
> Can you provide details ?
> 
>> 4. Hack around in the recipe with class overrides and exports
>>   - quickfix, no patch required
>>   - fails easily in the future
>> 
>> Any thoughts?
>> Stefan
>> 
> 
> 
> --
> Best regards,
> Marek Vasut
> --
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core at lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-core

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 204 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.openembedded.org/pipermail/openembedded-core/attachments/20161027/86c1df69/attachment-0002.sig>