sysroot question

sysroot question

[Zhang, Jessica]

[-- Attachment #1.1: Type: text/plain, Size: 1074 bytes --]

Hi Richard,
 
While testing the sysroot setup, I noticed there're some variation between
the sysroot that built by meta-toolchain and qemu-image-sdk.  For example,
limits.h, if I search for it under the meta-toolchain sysroot, I got the
following:
 
jzhang@jzhang-desktop:/opt/poky/0.9+snapshot$ find . -name limits.h
./sysroots/i586-poky-linux/usr/include/limits.h
./sysroots/i586-poky-linux/usr/include/linux/limits.h
./sysroots/i586-poky-linux/usr/include/c++/tr1/limits.h
./sysroots/i686-pokysdk-linux/usr/lib/i586-poky-linux/gcc/i586-poky-linux/4.
5.1/include-fixed/limits.h
./sysroots/i686-pokysdk-linux/usr/include/limits.h

 
and the sysroot extract from qemu-image-sdk, gave me this:
 
jzhang@jzhang-desktop:~/qemu-x86$ find . -name limits.h
./usr/lib/gcc/i586-poky-linux/4.5.1/include-fixed/limits.h
./usr/include/c++/tr1/limits.h
./usr/include/limits.h

This caused problem in test programs of suduku which looking for
<linux/limits.h>.  The question is where should I look that cause the
sysroot content variation?
 
Thanks,
Jessica

[-- Attachment #1.2: Type: text/html, Size: 2567 bytes --]

[-- Attachment #2: smime.p7s --]
[-- Type: application/x-pkcs7-signature, Size: 8455 bytes --]

Re: sysroot question

[Mark Hatle]

On 1/17/11 1:46 PM, Zhang, Jessica wrote:
> Hi Richard,
>  
> While testing the sysroot setup, I noticed there're some variation between the
> sysroot that built by meta-toolchain and qemu-image-sdk.  For example, limits.h,
> if I search for it under the meta-toolchain sysroot, I got the following:
>  
> jzhang@jzhang-desktop:/opt/poky/0.9+snapshot$
> <mailto:jzhang@jzhang-desktop:/opt/poky/0.9+snapshot$> find . -name limits.h
> ./sysroots/i586-poky-linux/usr/include/limits.h
> ./sysroots/i586-poky-linux/usr/include/linux/limits.h
> ./sysroots/i586-poky-linux/usr/include/c++/tr1/limits.h
> ./sysroots/i686-pokysdk-linux/usr/lib/i586-poky-linux/gcc/i586-poky-linux/4.5.1/include-fixed/limits.h
> ./sysroots/i686-pokysdk-linux/usr/include/limits.h
>  
> and the sysroot extract from qemu-image-sdk, gave me this:
>  
> jzhang@jzhang-desktop:~/qemu-x86$ <mailto:jzhang@jzhang-desktop:~/qemu-x86$>
> find . -name limits.h
> ./usr/lib/gcc/i586-poky-linux/4.5.1/include-fixed/limits.h
> ./usr/include/c++/tr1/limits.h
> ./usr/include/limits.h
> This caused problem in test programs of suduku which looking for
> <linux/limits.h>.  The question is where should I look that cause the sysroot
> content variation?

It is almost always a bug in an application to include <linux/*>.  The ONLY
valid exceptions are when they need an ioctl, syscall or similar definition that
is not available via the standard set of includes.

I highly doubt suduku fits this, so it's a bug in the test program.

(but yes, I also suspect that /usr/include/linux/... will be needed in the SDK,
so thats ALSO likely a defect..)

--Mark

> Thanks,
> Jessica
> 
> 
> 
> _______________________________________________
> poky mailing list
> poky@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/poky

sysroot question

[Gary Thomas]

I had a recipe that used to work and now fails after the change
to the split sysroots.  I'm building an out-of-tree kernel module
and patterned my recipe after the meta-skeleton example. My recipe
has this setup:

inherit module-base kernel-module-split

do_compile() {
	unset CFLAGS CPPFLAGS CXXFLAGS LDFLAGS
	oe_runmake KERNEL_PATH=${STAGING_KERNEL_DIR}   \
		   KERNEL_VERSION=${KERNEL_VERSION}    \
		   CC="${KERNEL_CC}" LD="${KERNEL_LD}" \
		   AR="${KERNEL_AR}" \
	           O=${STAGING_KERNEL_BUILDDIR} \
		   install
}

The problem is that ${CC} (arm-amltd-linux-gnueabi-gcc) can no longer be
found.  I know it's available, just not sure what needs to change to be
able to find it.

$ find tmp/work/teton_p7618-amltd-linux-gnueabi/my-module/ -name "arm*gcc"
tmp/work/teton_p7618-amltd-linux-gnueabi/my-module/5.2.2-r2-r0/recipe-sysroot-native/usr/libexec/arm-amltd-linux-gnueabi/gcc/arm-amltd-linux-gnueabi/5.4.0/arm-amltd-linux-gnueabi-gcc
tmp/work/teton_p7618-amltd-linux-gnueabi/my-module/5.2.2-r2-r0/recipe-sysroot-native/usr/bin/arm-amltd-linux-gnueabi/arm-amltd-linux-gnueabi-gcc


Any suggestions on how I fix this?

Thanks

-- 
------------------------------------------------------------
Gary Thomas                 |  Consulting for the
MLB Associates              |    Embedded world
------------------------------------------------------------

Re: sysroot question

[Gary Thomas]

On 2017-02-08 11:42, Gary Thomas wrote:
> I had a recipe that used to work and now fails after the change
> to the split sysroots.  I'm building an out-of-tree kernel module
> and patterned my recipe after the meta-skeleton example. My recipe
> has this setup:
>
> inherit module-base kernel-module-split
>
> do_compile() {
>     unset CFLAGS CPPFLAGS CXXFLAGS LDFLAGS
>     oe_runmake KERNEL_PATH=${STAGING_KERNEL_DIR}   \
>            KERNEL_VERSION=${KERNEL_VERSION}    \
>            CC="${KERNEL_CC}" LD="${KERNEL_LD}" \
>            AR="${KERNEL_AR}" \
>                O=${STAGING_KERNEL_BUILDDIR} \
>            install
> }
>
> The problem is that ${CC} (arm-amltd-linux-gnueabi-gcc) can no longer be
> found.  I know it's available, just not sure what needs to change to be
> able to find it.
>
> $ find tmp/work/teton_p7618-amltd-linux-gnueabi/my-module/ -name "arm*gcc"
> tmp/work/teton_p7618-amltd-linux-gnueabi/my-module/5.2.2-r2-r0/recipe-sysroot-native/usr/libexec/arm-amltd-linux-gnueabi/gcc/arm-amltd-linux-gnueabi/5.4.0/arm-amltd-linux-gnueabi-gcc
>
> tmp/work/teton_p7618-amltd-linux-gnueabi/my-module/5.2.2-r2-r0/recipe-sysroot-native/usr/bin/arm-amltd-linux-gnueabi/arm-amltd-linux-gnueabi-gcc
>
>
>
> Any suggestions on how I fix this?
>
> Thanks
>

It looks like the failure is actually happening in a class method (make_scripts)
My recipe also contains this
   addtask make_scripts after do_patch before do_compile
which doesn't seem to be setting the ${PATH} correctly anymore.

Any ideas what might be missing?

Note: just moving the call to do_make_scripts to the top of do_compile
instead of running it as a separate task fixes the problem.

-- 
------------------------------------------------------------
Gary Thomas                 |  Consulting for the
MLB Associates              |    Embedded world
------------------------------------------------------------

Re: sysroot question

[Joshua Lock]

On Wed, 2017-02-08 at 12:12 +0100, Gary Thomas wrote:
> On 2017-02-08 11:42, Gary Thomas wrote:
> > I had a recipe that used to work and now fails after the change
> > to the split sysroots.  I'm building an out-of-tree kernel module
> > and patterned my recipe after the meta-skeleton example. My recipe
> > has this setup:
> > 
> > inherit module-base kernel-module-split
> > 
> > do_compile() {
> >     unset CFLAGS CPPFLAGS CXXFLAGS LDFLAGS
> >     oe_runmake KERNEL_PATH=${STAGING_KERNEL_DIR}   \
> >            KERNEL_VERSION=${KERNEL_VERSION}    \
> >            CC="${KERNEL_CC}" LD="${KERNEL_LD}" \
> >            AR="${KERNEL_AR}" \
> >                O=${STAGING_KERNEL_BUILDDIR} \
> >            install
> > }
> > 
> > The problem is that ${CC} (arm-amltd-linux-gnueabi-gcc) can no
> > longer be
> > found.  I know it's available, just not sure what needs to change
> > to be
> > able to find it.
> > 
> > $ find tmp/work/teton_p7618-amltd-linux-gnueabi/my-module/ -name
> > "arm*gcc"
> > tmp/work/teton_p7618-amltd-linux-gnueabi/my-module/5.2.2-r2-
> > r0/recipe-sysroot-native/usr/libexec/arm-amltd-linux-
> > gnueabi/gcc/arm-amltd-linux-gnueabi/5.4.0/arm-amltd-linux-gnueabi-
> > gcc
> > 
> > tmp/work/teton_p7618-amltd-linux-gnueabi/my-module/5.2.2-r2-
> > r0/recipe-sysroot-native/usr/bin/arm-amltd-linux-gnueabi/arm-amltd-
> > linux-gnueabi-gcc
> > 
> > 
> > 
> > Any suggestions on how I fix this?
> > 
> > Thanks
> > 
> 
> It looks like the failure is actually happening in a class method
> (make_scripts)
> My recipe also contains this
>    addtask make_scripts after do_patch before do_compile
> which doesn't seem to be setting the ${PATH} correctly anymore.
> 
> Any ideas what might be missing?

Does make_scripts set cwd using the dirs varflag?

http://www.yoctoproject.org/docs/latest/bitbake-user-manual/bitbake-use
r-manual.html#variable-flags

i.e. meta/classes/base.bbclass:do_compile[dirs] = "${B}"

Joshua

Re: sysroot question

[Paul Eggleton]

Hi Gary,

On Wednesday, 8 February 2017 12:12:25 PM NZDT Gary Thomas wrote:
> On 2017-02-08 11:42, Gary Thomas wrote:
> > I had a recipe that used to work and now fails after the change
> > to the split sysroots.  I'm building an out-of-tree kernel module
> > and patterned my recipe after the meta-skeleton example. My recipe
> > has this setup:
> > 
> > inherit module-base kernel-module-split
> > 
> > do_compile() {
> > 
> >     unset CFLAGS CPPFLAGS CXXFLAGS LDFLAGS
> >     oe_runmake KERNEL_PATH=${STAGING_KERNEL_DIR}   \
> >     
> >            KERNEL_VERSION=${KERNEL_VERSION}    \
> >            CC="${KERNEL_CC}" LD="${KERNEL_LD}" \
> >            AR="${KERNEL_AR}" \
> >            
> >                O=${STAGING_KERNEL_BUILDDIR} \
> >            
> >            install
> > 
> > }
> > 
> > The problem is that ${CC} (arm-amltd-linux-gnueabi-gcc) can no longer be
> > found.  I know it's available, just not sure what needs to change to be
> > able to find it.
> > 
> > $ find tmp/work/teton_p7618-amltd-linux-gnueabi/my-module/ -name "arm*gcc"
> > tmp/work/teton_p7618-amltd-linux-gnueabi/my-module/5.2.2-r2-r0/recipe-sysr
> > oot-native/usr/libexec/arm-amltd-linux-gnueabi/gcc/arm-amltd-linux-gnueabi
> > /5.4.0/arm-amltd-linux-gnueabi-gcc
> > 
> > tmp/work/teton_p7618-amltd-linux-gnueabi/my-module/5.2.2-r2-r0/recipe-sysr
> > oot-native/usr/bin/arm-amltd-linux-gnueabi/arm-amltd-linux-gnueabi-gcc
> 
> It looks like the failure is actually happening in a class method
> (make_scripts) My recipe also contains this
>    addtask make_scripts after do_patch before do_compile
> which doesn't seem to be setting the ${PATH} correctly anymore.
> 
> Any ideas what might be missing?
> 
> Note: just moving the call to do_make_scripts to the top of do_compile
> instead of running it as a separate task fixes the problem.

I think the problem is that the task that prepares the sysroot 
(do_prepare_recipe_sysroot) isn't a dependency of your task. module.bbclass  
uses this:

addtask make_scripts after do_prepare_recipe_sysroot before do_compile

BTW you say you patterned your recipe after the skeleton example, except 
hello-mod at least currently inherits module rather than module-base + kernel-
module-split - is there a compelling reason not to inherit module?

Cheers,
Paul

-- 

Paul Eggleton
Intel Open Source Technology Centre

Re: sysroot question

[Gary Thomas]

On 2017-02-08 20:36, Paul Eggleton wrote:
> Hi Gary,
>
> On Wednesday, 8 February 2017 12:12:25 PM NZDT Gary Thomas wrote:
>> On 2017-02-08 11:42, Gary Thomas wrote:
>>> I had a recipe that used to work and now fails after the change
>>> to the split sysroots.  I'm building an out-of-tree kernel module
>>> and patterned my recipe after the meta-skeleton example. My recipe
>>> has this setup:
>>>
>>> inherit module-base kernel-module-split
>>>
>>> do_compile() {
>>>
>>>     unset CFLAGS CPPFLAGS CXXFLAGS LDFLAGS
>>>     oe_runmake KERNEL_PATH=${STAGING_KERNEL_DIR}   \
>>>
>>>            KERNEL_VERSION=${KERNEL_VERSION}    \
>>>            CC="${KERNEL_CC}" LD="${KERNEL_LD}" \
>>>            AR="${KERNEL_AR}" \
>>>
>>>                O=${STAGING_KERNEL_BUILDDIR} \
>>>
>>>            install
>>>
>>> }
>>>
>>> The problem is that ${CC} (arm-amltd-linux-gnueabi-gcc) can no longer be
>>> found.  I know it's available, just not sure what needs to change to be
>>> able to find it.
>>>
>>> $ find tmp/work/teton_p7618-amltd-linux-gnueabi/my-module/ -name "arm*gcc"
>>> tmp/work/teton_p7618-amltd-linux-gnueabi/my-module/5.2.2-r2-r0/recipe-sysr
>>> oot-native/usr/libexec/arm-amltd-linux-gnueabi/gcc/arm-amltd-linux-gnueabi
>>> /5.4.0/arm-amltd-linux-gnueabi-gcc
>>>
>>> tmp/work/teton_p7618-amltd-linux-gnueabi/my-module/5.2.2-r2-r0/recipe-sysr
>>> oot-native/usr/bin/arm-amltd-linux-gnueabi/arm-amltd-linux-gnueabi-gcc
>>
>> It looks like the failure is actually happening in a class method
>> (make_scripts) My recipe also contains this
>>    addtask make_scripts after do_patch before do_compile
>> which doesn't seem to be setting the ${PATH} correctly anymore.
>>
>> Any ideas what might be missing?
>>
>> Note: just moving the call to do_make_scripts to the top of do_compile
>> instead of running it as a separate task fixes the problem.
>
> I think the problem is that the task that prepares the sysroot
> (do_prepare_recipe_sysroot) isn't a dependency of your task. module.bbclass
> uses this:
>
> addtask make_scripts after do_prepare_recipe_sysroot before do_compile
>
> BTW you say you patterned your recipe after the skeleton example, except
> hello-mod at least currently inherits module rather than module-base + kernel-
> module-split - is there a compelling reason not to inherit module?

I may have been mistaken about the original source - it looks like I
used a similar module strategy from meta-freescale.  I did [just now]
try using "inherit module" and the build dies a horrible death with
this error
| make: *** No rule to make target 'modules_install'.  Stop.

I changed my [task] dependencies to match what you've quoted and everything
works as before.  !Thanks!

-- 
------------------------------------------------------------
Gary Thomas                 |  Consulting for the
MLB Associates              |    Embedded world
------------------------------------------------------------

Re: sysroot question

[Anders Darander]

* Gary Thomas <gary@mlbassoc.com> [170209 05:25]:
> On 2017-02-08 20:36, Paul Eggleton wrote:
> > I think the problem is that the task that prepares the sysroot
> > (do_prepare_recipe_sysroot) isn't a dependency of your task. module.bbclass
> > uses this:

> > addtask make_scripts after do_prepare_recipe_sysroot before do_compile

> > BTW you say you patterned your recipe after the skeleton example, except
> > hello-mod at least currently inherits module rather than module-base + kernel-
> > module-split - is there a compelling reason not to inherit module?

> I may have been mistaken about the original source - it looks like I
> used a similar module strategy from meta-freescale.  I did [just now]
> try using "inherit module" and the build dies a horrible death with
> this error
> | make: *** No rule to make target 'modules_install'.  Stop.

Well, that is simple to solve. module.bbclasses sets

MODULES_INSTALL_TARGET ?= "modules_install"

just override that with your own install target. (Or fix the module's
Makefile). The last option is to simply override do_install in your
recipe.

> I changed my [task] dependencies to match what you've quoted and everything
> works as before.  !Thanks!

I'd still recommend doing as little as possible in each recipe, and
leverage the standard modules.

Cheers,
Anders

-- 
Anders Darander, Senior System Architect
ChargeStorm AB / eStorm AB

Re: sysroot question

[Gary Thomas]

On 2017-02-09 08:49, Anders Darander wrote:
> * Gary Thomas <gary@mlbassoc.com> [170209 05:25]:
>> On 2017-02-08 20:36, Paul Eggleton wrote:
>>> I think the problem is that the task that prepares the sysroot
>>> (do_prepare_recipe_sysroot) isn't a dependency of your task. module.bbclass
>>> uses this:
>
>>> addtask make_scripts after do_prepare_recipe_sysroot before do_compile
>
>>> BTW you say you patterned your recipe after the skeleton example, except
>>> hello-mod at least currently inherits module rather than module-base + kernel-
>>> module-split - is there a compelling reason not to inherit module?
>
>> I may have been mistaken about the original source - it looks like I
>> used a similar module strategy from meta-freescale.  I did [just now]
>> try using "inherit module" and the build dies a horrible death with
>> this error
>> | make: *** No rule to make target 'modules_install'.  Stop.
>
> Well, that is simple to solve. module.bbclasses sets
>
> MODULES_INSTALL_TARGET ?= "modules_install"
>
> just override that with your own install target. (Or fix the module's
> Makefile). The last option is to simply override do_install in your
> recipe.

I already override do_install(), so that's not enough.

>
>> I changed my [task] dependencies to match what you've quoted and everything
>> works as before.  !Thanks!
>
> I'd still recommend doing as little as possible in each recipe, and
> leverage the standard modules.

-- 
------------------------------------------------------------
Gary Thomas                 |  Consulting for the
MLB Associates              |    Embedded world
------------------------------------------------------------