u-boot compile failure

u-boot compile failure

[Jack Mitchell]

It seems that u-boot is attempting to use GCC includes from my host 
system here. This surely isn't right is it?

DEBUG: Executing shell function do_compile
NOTE: make -j 9 HOSTCC=gcc  HOSTLD=ld 
HOSTLDFLAGS=-L/home/jack/Projects/poky-r0005/R0005/tmp/sysroots/x86_64-linux/usr/lib 
-L/home/jack/Projects/poky-r0005/R0005/tmp/sysroots/x86_64-linux/lib 
-Wl,-rpath-link,/home/jack/Projects/poky-r0005/R0005/tmp/sysroots/x86_64-linux/usr/lib 
-Wl,-rpath-link,/home/jack/Projects/poky-r0005/R0005/tmp/sysroots/x86_64-linux/lib 
-Wl,-rpath,/home/jack/Projects/poky-r0005/R0005/tmp/sysroots/x86_64-linux/usr/lib 
-Wl,-rpath,/home/jack/Projects/poky-r0005/R0005/tmp/sysroots/x86_64-linux/lib 
-Wl,-O1 HOSTSTRIP=true tools
make -C tools all
make[1]: Entering directory 
`/home/jack/Projects/poky-r0005/R0005/tmp/work/x86_64-linux/u-boot-mkimage-native-2011.06-r0/u-boot-2011.06/tools'
make[1]: *** No rule to make target 
`/usr/lib/gcc/x86_64-unknown-linux-gnu/4.7.1/include/stddef.h', needed 
by `crc32.o'.  Stop.
make[1]: Leaving directory 
`/home/jack/Projects/poky-r0005/R0005/tmp/work/x86_64-linux/u-boot-mkimage-native-2011.06-r0/u-boot-2011.06/tools'
make: *** [tools] Error 2
ERROR: oe_runmake failed
ERROR: Function failed: do_compile (see 
/home/jack/Projects/poky-r0005/R0005/tmp/work/x86_64-linux/u-boot-mkimage-native-2011.06-r0/temp/log.do_compile.15275 
for further information)

-- 

   Jack Mitchell (jack@embed.me.uk)
   Embedded Systems Engineer
   http://www.embed.me.uk

--

Re: u-boot compile failure

[Tom Rini]

On Mon, Oct 15, 2012 at 6:32 AM, Jack Mitchell <ml@communistcode.co.uk> wrote:
> It seems that u-boot is attempting to use GCC includes from my host system
> here. This surely isn't right is it?

There are host tools to build.  That said, from the log it looks like
you have been trying to build this a few times.  If you bitbake -c
clean u-boot do you still see the problem?

-- 
Tom

Re: u-boot compile failure

[Jack Mitchell]

On 16/10/12 02:20, Tom Rini wrote:
> On Mon, Oct 15, 2012 at 6:32 AM, Jack Mitchell <ml@communistcode.co.uk> wrote:
>> It seems that u-boot is attempting to use GCC includes from my host system
>> here. This surely isn't right is it?
> There are host tools to build.  That said, from the log it looks like
> you have been trying to build this a few times.  If you bitbake -c
> clean u-boot do you still see the problem?
>
I get the error[1] after the -c clean.

I think I know what it is, that I upgraded my host distro yesterday 
which pulled in a new GCC and the old GCC libraries are still in the 
path. However, bitbake shouldn't be going into the host system for 
includes should it? Shouldn't it use it's own compiled GCC and 
associated libraries to generate the u-boot tools rather than rely on 
whatever is present on my host system, or am I missing something? I'm 
pretty sure a reboot would sort it out but I didn't want to kill a 
failure case.

Regards,

[1]

[jack@archHP R0005]$ bitbake -c clean u-boot
WARNING: Host distribution could not be determined; you may possibly 
experience unexpected failures. It is recommended that you use a tested 
distribution.
Parsing recipes: 100% |#########################################| Time: 
00:00:17
Parsing of 897 .bb files complete (0 cached, 897 parsed). 1206 targets, 
60 skipped, 8 masked, 0 errors.

Build Configuration:
BB_VERSION        = "1.16.0"
TARGET_ARCH       = "arm"
TARGET_OS         = "linux-gnueabi"
MACHINE           = "beaglebone"
DISTRO            = "poky"
DISTRO_VERSION    = "1.3+snapshot-20121016"
TUNE_FEATURES     = "armv7a vfp neon cortexa8"
TARGET_FPU        = "vfp-neon"
meta
meta-yocto        = "master:83448c4b318ce60a54aae24a9a247456fa94caaf"
meta-ti           = "master:2a3c7305fb81967d1358e731fb564182480b0338"
meta-db           = "master:4dbfea5ae4acf397d4e28a3b164860f4c8064801"

NOTE: Resolving any missing task queue dependencies
NOTE: Preparing runqueue
NOTE: Executing RunQueue Tasks
NOTE: Tasks Summary: Attempted 1 tasks of which 0 didn't need to be 
rerun and all succeeded.

Summary: There was 1 WARNING message shown.
[jack@archHP R0005]$ bitbake core-image-db
WARNING: Host distribution could not be determined; you may possibly 
experience unexpected failures. It is recommended that you use a tested 
distribution.
Loading cache: 100% |###########################################| ETA:  
00:00:00
Loaded 1207 entries from dependency cache.

Build Configuration:
BB_VERSION        = "1.16.0"
TARGET_ARCH       = "arm"
TARGET_OS         = "linux-gnueabi"
MACHINE           = "beaglebone"
DISTRO            = "poky"
DISTRO_VERSION    = "1.3+snapshot-20121016"
TUNE_FEATURES     = "armv7a vfp neon cortexa8"
TARGET_FPU        = "vfp-neon"
meta
meta-yocto        = "master:83448c4b318ce60a54aae24a9a247456fa94caaf"
meta-ti           = "master:2a3c7305fb81967d1358e731fb564182480b0338"
meta-db           = "master:4dbfea5ae4acf397d4e28a3b164860f4c8064801"

NOTE: Resolving any missing task queue dependencies
NOTE: Preparing runqueue
NOTE: Executing SetScene Tasks
NOTE: Executing RunQueue Tasks
ERROR: Function failed: do_compile (see 
/home/jack/Projects/poky-r0005/R0005/tmp/work/x86_64-linux/u-boot-mkimage-native-2011.06-r0/temp/log.do_compile.8359 
for further information)
ERROR: Logfile of failure stored in: 
/home/jack/Projects/poky-r0005/R0005/tmp/work/x86_64-linux/u-boot-mkimage-native-2011.06-r0/temp/log.do_compile.8359
Log data follows:
| DEBUG: Executing shell function do_compile
| NOTE: make -j 9 HOSTCC=gcc  HOSTLD=ld 
HOSTLDFLAGS=-L/home/jack/Projects/poky-r0005/R0005/tmp/sysroots/x86_64-linux/usr/lib 
-L/home/jack/Projects/poky-r0005/R0005/tmp/sysroots/x86_64-linux/lib 
-Wl,-rpath-link,/home/jack/Projects/poky-r0005/R0005/tmp/sysroots/x86_64-linux/usr/lib 
-Wl,-rpath-link,/home/jack/Projects/poky-r0005/R0005/tmp/sysroots/x86_64-linux/lib 
-Wl,-rpath,/home/jack/Projects/poky-r0005/R0005/tmp/sysroots/x86_64-linux/usr/lib 
-Wl,-rpath,/home/jack/Projects/poky-r0005/R0005/tmp/sysroots/x86_64-linux/lib 
-Wl,-O1 HOSTSTRIP=true tools
| make -C tools all
| make[1]: Entering directory 
`/home/jack/Projects/poky-r0005/R0005/tmp/work/x86_64-linux/u-boot-mkimage-native-2011.06-r0/u-boot-2011.06/tools'
| make[1]: *** No rule to make target 
`/usr/lib/gcc/x86_64-unknown-linux-gnu/4.7.1/include/stddef.h', needed 
by `crc32.o'.  Stop.
| make[1]: Leaving directory 
`/home/jack/Projects/poky-r0005/R0005/tmp/work/x86_64-linux/u-boot-mkimage-native-2011.06-r0/u-boot-2011.06/tools'
| make: *** [tools] Error 2
| ERROR: oe_runmake failed
| ERROR: Function failed: do_compile (see 
/home/jack/Projects/poky-r0005/R0005/tmp/work/x86_64-linux/u-boot-mkimage-native-2011.06-r0/temp/log.do_compile.8359 
for further information)
ERROR: Task 1688 
(virtual:native:/home/jack/Projects/poky-r0005/meta/recipes-bsp/u-boot/u-boot-mkimage_2011.06.bb, 
do_compile) failed with exit code '1'
NOTE: Tasks Summary: Attempted 757 tasks of which 742 didn't need to be 
rerun and 1 failed.
Waiting for 0 running tasks to finish:

Summary: 1 task failed:
virtual:native:/home/jack/Projects/poky-r0005/meta/recipes-bsp/u-boot/u-boot-mkimage_2011.06.bb, 
do_compile
Summary: There was 1 WARNING message shown.
Summary: There was 1 ERROR message shown, returning a non-zero exit code.
[jack@archHP R0005]$


-- 

   Jack Mitchell (jack@embed.me.uk)
   Embedded Systems Engineer
   http://www.embed.me.uk

--

Re: u-boot compile failure

[Denys Dmytriyenko]

On Tue, Oct 16, 2012 at 09:22:57AM +0100, Jack Mitchell wrote:
> On 16/10/12 02:20, Tom Rini wrote:
> >On Mon, Oct 15, 2012 at 6:32 AM, Jack Mitchell <ml@communistcode.co.uk> wrote:
> >>It seems that u-boot is attempting to use GCC includes from my host system
> >>here. This surely isn't right is it?
> >There are host tools to build.  That said, from the log it looks like
> >you have been trying to build this a few times.  If you bitbake -c
> >clean u-boot do you still see the problem?
> >
> I get the error[1] after the -c clean.
> 
> I think I know what it is, that I upgraded my host distro yesterday
> which pulled in a new GCC and the old GCC libraries are still in the
> path. However, bitbake shouldn't be going into the host system for
> includes should it? Shouldn't it use it's own compiled GCC and
> associated libraries to generate the u-boot tools rather than rely
> on whatever is present on my host system, or am I missing something?
> I'm pretty sure a reboot would sort it out but I didn't want to kill
> a failure case.

Jack,

It's not u-boot that fails for you, it's u-boot-mkimage-native - it's a host 
tool to generate u-boot images, so it runs on your host and hence is built 
with your host compiler. OE/Yocto usually builds bunch of host tools and they 
have the "-native" suffix in their names. Upgradig your host system w/o 
switching profiles or changing paths is a common issue in such cases.

-- 
Denys


> Regards,
> 
> [1]
> 
> [jack@archHP R0005]$ bitbake -c clean u-boot
> WARNING: Host distribution could not be determined; you may possibly
> experience unexpected failures. It is recommended that you use a
> tested distribution.
> Parsing recipes: 100% |#########################################|
> Time: 00:00:17
> Parsing of 897 .bb files complete (0 cached, 897 parsed). 1206
> targets, 60 skipped, 8 masked, 0 errors.
> 
> Build Configuration:
> BB_VERSION        = "1.16.0"
> TARGET_ARCH       = "arm"
> TARGET_OS         = "linux-gnueabi"
> MACHINE           = "beaglebone"
> DISTRO            = "poky"
> DISTRO_VERSION    = "1.3+snapshot-20121016"
> TUNE_FEATURES     = "armv7a vfp neon cortexa8"
> TARGET_FPU        = "vfp-neon"
> meta
> meta-yocto        = "master:83448c4b318ce60a54aae24a9a247456fa94caaf"
> meta-ti           = "master:2a3c7305fb81967d1358e731fb564182480b0338"
> meta-db           = "master:4dbfea5ae4acf397d4e28a3b164860f4c8064801"
> 
> NOTE: Resolving any missing task queue dependencies
> NOTE: Preparing runqueue
> NOTE: Executing RunQueue Tasks
> NOTE: Tasks Summary: Attempted 1 tasks of which 0 didn't need to be
> rerun and all succeeded.
> 
> Summary: There was 1 WARNING message shown.
> [jack@archHP R0005]$ bitbake core-image-db
> WARNING: Host distribution could not be determined; you may possibly
> experience unexpected failures. It is recommended that you use a
> tested distribution.
> Loading cache: 100% |###########################################|
> ETA:  00:00:00
> Loaded 1207 entries from dependency cache.
> 
> Build Configuration:
> BB_VERSION        = "1.16.0"
> TARGET_ARCH       = "arm"
> TARGET_OS         = "linux-gnueabi"
> MACHINE           = "beaglebone"
> DISTRO            = "poky"
> DISTRO_VERSION    = "1.3+snapshot-20121016"
> TUNE_FEATURES     = "armv7a vfp neon cortexa8"
> TARGET_FPU        = "vfp-neon"
> meta
> meta-yocto        = "master:83448c4b318ce60a54aae24a9a247456fa94caaf"
> meta-ti           = "master:2a3c7305fb81967d1358e731fb564182480b0338"
> meta-db           = "master:4dbfea5ae4acf397d4e28a3b164860f4c8064801"
> 
> NOTE: Resolving any missing task queue dependencies
> NOTE: Preparing runqueue
> NOTE: Executing SetScene Tasks
> NOTE: Executing RunQueue Tasks
> ERROR: Function failed: do_compile (see /home/jack/Projects/poky-r0005/R0005/tmp/work/x86_64-linux/u-boot-mkimage-native-2011.06-r0/temp/log.do_compile.8359
> for further information)
> ERROR: Logfile of failure stored in: /home/jack/Projects/poky-r0005/R0005/tmp/work/x86_64-linux/u-boot-mkimage-native-2011.06-r0/temp/log.do_compile.8359
> Log data follows:
> | DEBUG: Executing shell function do_compile
> | NOTE: make -j 9 HOSTCC=gcc  HOSTLD=ld HOSTLDFLAGS=-L/home/jack/Projects/poky-r0005/R0005/tmp/sysroots/x86_64-linux/usr/lib
> -L/home/jack/Projects/poky-r0005/R0005/tmp/sysroots/x86_64-linux/lib -Wl,-rpath-link,/home/jack/Projects/poky-r0005/R0005/tmp/sysroots/x86_64-linux/usr/lib -Wl,-rpath-link,/home/jack/Projects/poky-r0005/R0005/tmp/sysroots/x86_64-linux/lib -Wl,-rpath,/home/jack/Projects/poky-r0005/R0005/tmp/sysroots/x86_64-linux/usr/lib -Wl,-rpath,/home/jack/Projects/poky-r0005/R0005/tmp/sysroots/x86_64-linux/lib
> -Wl,-O1 HOSTSTRIP=true tools
> | make -C tools all
> | make[1]: Entering directory `/home/jack/Projects/poky-r0005/R0005/tmp/work/x86_64-linux/u-boot-mkimage-native-2011.06-r0/u-boot-2011.06/tools'
> | make[1]: *** No rule to make target
> `/usr/lib/gcc/x86_64-unknown-linux-gnu/4.7.1/include/stddef.h',
> needed by `crc32.o'.  Stop.
> | make[1]: Leaving directory `/home/jack/Projects/poky-r0005/R0005/tmp/work/x86_64-linux/u-boot-mkimage-native-2011.06-r0/u-boot-2011.06/tools'
> | make: *** [tools] Error 2
> | ERROR: oe_runmake failed
> | ERROR: Function failed: do_compile (see /home/jack/Projects/poky-r0005/R0005/tmp/work/x86_64-linux/u-boot-mkimage-native-2011.06-r0/temp/log.do_compile.8359
> for further information)
> ERROR: Task 1688 (virtual:native:/home/jack/Projects/poky-r0005/meta/recipes-bsp/u-boot/u-boot-mkimage_2011.06.bb,
> do_compile) failed with exit code '1'
> NOTE: Tasks Summary: Attempted 757 tasks of which 742 didn't need to
> be rerun and 1 failed.
> Waiting for 0 running tasks to finish:
> 
> Summary: 1 task failed:
> virtual:native:/home/jack/Projects/poky-r0005/meta/recipes-bsp/u-boot/u-boot-mkimage_2011.06.bb,
> do_compile
> Summary: There was 1 WARNING message shown.
> Summary: There was 1 ERROR message shown, returning a non-zero exit code.
> [jack@archHP R0005]$
> 
> 
> -- 
> 
>   Jack Mitchell (jack@embed.me.uk)
>   Embedded Systems Engineer
>   http://www.embed.me.uk
> 
> --
> 
> _______________________________________________
> meta-ti mailing list
> meta-ti@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/meta-ti
> 

Re: u-boot compile failure

[Jack Mitchell]

On 16/10/12 14:00, Denys Dmytriyenko wrote:
> On Tue, Oct 16, 2012 at 09:22:57AM +0100, Jack Mitchell wrote:
>> On 16/10/12 02:20, Tom Rini wrote:
>>> On Mon, Oct 15, 2012 at 6:32 AM, Jack Mitchell <ml@communistcode.co.uk> wrote:
>>>> It seems that u-boot is attempting to use GCC includes from my host system
>>>> here. This surely isn't right is it?
>>> There are host tools to build.  That said, from the log it looks like
>>> you have been trying to build this a few times.  If you bitbake -c
>>> clean u-boot do you still see the problem?
>>>
>> I get the error[1] after the -c clean.
>>
>> I think I know what it is, that I upgraded my host distro yesterday
>> which pulled in a new GCC and the old GCC libraries are still in the
>> path. However, bitbake shouldn't be going into the host system for
>> includes should it? Shouldn't it use it's own compiled GCC and
>> associated libraries to generate the u-boot tools rather than rely
>> on whatever is present on my host system, or am I missing something?
>> I'm pretty sure a reboot would sort it out but I didn't want to kill
>> a failure case.
> Jack,
>
> It's not u-boot that fails for you, it's u-boot-mkimage-native - it's a host
> tool to generate u-boot images, so it runs on your host and hence is built
> with your host compiler. OE/Yocto usually builds bunch of host tools and they
> have the "-native" suffix in their names. Upgradig your host system w/o
> switching profiles or changing paths is a common issue in such cases.
>

Ok, so when a package is labelled -native it is not only native in 
architecture but linked to the specific host?

This is just out of interest since I was unaware of the level of host 
intrusion on a build.

-- 

   Jack Mitchell (jack@embed.me.uk)
   Embedded Systems Engineer
   http://www.embed.me.uk

--

Re: u-boot compile failure

[Denys Dmytriyenko]

On Tue, Oct 16, 2012 at 02:16:14PM +0100, Jack Mitchell wrote:
> On 16/10/12 14:00, Denys Dmytriyenko wrote:
> >On Tue, Oct 16, 2012 at 09:22:57AM +0100, Jack Mitchell wrote:
> >>On 16/10/12 02:20, Tom Rini wrote:
> >>>On Mon, Oct 15, 2012 at 6:32 AM, Jack Mitchell <ml@communistcode.co.uk> wrote:
> >>>>It seems that u-boot is attempting to use GCC includes from my host system
> >>>>here. This surely isn't right is it?
> >>>There are host tools to build.  That said, from the log it looks like
> >>>you have been trying to build this a few times.  If you bitbake -c
> >>>clean u-boot do you still see the problem?
> >>>
> >>I get the error[1] after the -c clean.
> >>
> >>I think I know what it is, that I upgraded my host distro yesterday
> >>which pulled in a new GCC and the old GCC libraries are still in the
> >>path. However, bitbake shouldn't be going into the host system for
> >>includes should it? Shouldn't it use it's own compiled GCC and
> >>associated libraries to generate the u-boot tools rather than rely
> >>on whatever is present on my host system, or am I missing something?
> >>I'm pretty sure a reboot would sort it out but I didn't want to kill
> >>a failure case.
> >Jack,
> >
> >It's not u-boot that fails for you, it's u-boot-mkimage-native - it's a host
> >tool to generate u-boot images, so it runs on your host and hence is built
> >with your host compiler. OE/Yocto usually builds bunch of host tools and they
> >have the "-native" suffix in their names. Upgradig your host system w/o
> >switching profiles or changing paths is a common issue in such cases.
> >
> 
> Ok, so when a package is labelled -native it is not only native in
> architecture but linked to the specific host?

Yes, because that code is used locally on the same host and only for the 
build. You don't ship that code, as it doesn't even get packaged anywhere - 
it gets populated in the sysroots and used for the builds.

For something that you need to distribute/ship, that needs to run on a host, 
there's SDK with Canadian cross, where you get a complete separation and host 
binaries that are not linked to a specific host. Moreover, you can target 
32bit x86 SDK host, while building it on a 64bit-only x86 build host. Those 
are marked with "-nativesdk" suffix instead.

> This is just out of interest since I was unaware of the level of
> host intrusion on a build.

-- 
Denys

Re: u-boot compile failure

[Jack Mitchell]

On 16/10/12 14:37, Denys Dmytriyenko wrote:
> On Tue, Oct 16, 2012 at 02:16:14PM +0100, Jack Mitchell wrote:
>> On 16/10/12 14:00, Denys Dmytriyenko wrote:
>>> On Tue, Oct 16, 2012 at 09:22:57AM +0100, Jack Mitchell wrote:
>>>> On 16/10/12 02:20, Tom Rini wrote:
>>>>> On Mon, Oct 15, 2012 at 6:32 AM, Jack Mitchell <ml@communistcode.co.uk> wrote:
>>>>>> It seems that u-boot is attempting to use GCC includes from my host system
>>>>>> here. This surely isn't right is it?
>>>>> There are host tools to build.  That said, from the log it looks like
>>>>> you have been trying to build this a few times.  If you bitbake -c
>>>>> clean u-boot do you still see the problem?
>>>>>
>>>> I get the error[1] after the -c clean.
>>>>
>>>> I think I know what it is, that I upgraded my host distro yesterday
>>>> which pulled in a new GCC and the old GCC libraries are still in the
>>>> path. However, bitbake shouldn't be going into the host system for
>>>> includes should it? Shouldn't it use it's own compiled GCC and
>>>> associated libraries to generate the u-boot tools rather than rely
>>>> on whatever is present on my host system, or am I missing something?
>>>> I'm pretty sure a reboot would sort it out but I didn't want to kill
>>>> a failure case.
>>> Jack,
>>>
>>> It's not u-boot that fails for you, it's u-boot-mkimage-native - it's a host
>>> tool to generate u-boot images, so it runs on your host and hence is built
>>> with your host compiler. OE/Yocto usually builds bunch of host tools and they
>>> have the "-native" suffix in their names. Upgradig your host system w/o
>>> switching profiles or changing paths is a common issue in such cases.
>>>
>> Ok, so when a package is labelled -native it is not only native in
>> architecture but linked to the specific host?
> Yes, because that code is used locally on the same host and only for the
> build. You don't ship that code, as it doesn't even get packaged anywhere -
> it gets populated in the sysroots and used for the builds.
>
> For something that you need to distribute/ship, that needs to run on a host,
> there's SDK with Canadian cross, where you get a complete separation and host
> binaries that are not linked to a specific host. Moreover, you can target
> 32bit x86 SDK host, while building it on a 64bit-only x86 build host. Those
> are marked with "-nativesdk" suffix instead.

Bingo, that answered every question I had lingering - even including the 
one about building different native for different architectures that I 
resisted asking! ;)

Thanks Denys - I'll get there eventually!

>
>> This is just out of interest since I was unaware of the level of
>> host intrusion on a build.


-- 

   Jack Mitchell (jack@embed.me.uk)
   Embedded Systems Engineer
   http://www.embed.me.uk

--