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 <[email protected] >>>> <mailto:[email protected]>> 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! 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. 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 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 4. Hack around in the recipe with class overrides and exports - quickfix, no patch required - fails easily in the future
Any thoughts? Stefan -- _______________________________________________ Openembedded-core mailing list [email protected] http://lists.openembedded.org/mailman/listinfo/openembedded-core
