> On Oct 27, 2016, at 5:18 PM, Marek Vasut <[email protected]> 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 <[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! > > 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 > [email protected] > http://lists.openembedded.org/mailman/listinfo/openembedded-core
signature.asc
Description: Message signed with OpenPGP using GPGMail
-- _______________________________________________ Openembedded-core mailing list [email protected] http://lists.openembedded.org/mailman/listinfo/openembedded-core
