* sysroot question
@ 2017-02-08 10:42 Gary Thomas
2017-02-08 11:12 ` Gary Thomas
0 siblings, 1 reply; 9+ messages in thread
From: Gary Thomas @ 2017-02-08 10:42 UTC (permalink / raw)
To: yocto
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
------------------------------------------------------------
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: sysroot question
2017-02-08 10:42 sysroot question Gary Thomas
@ 2017-02-08 11:12 ` Gary Thomas
2017-02-08 13:57 ` Joshua Lock
2017-02-08 19:36 ` Paul Eggleton
0 siblings, 2 replies; 9+ messages in thread
From: Gary Thomas @ 2017-02-08 11:12 UTC (permalink / raw)
To: yocto
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
------------------------------------------------------------
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: sysroot question
2017-02-08 11:12 ` Gary Thomas
@ 2017-02-08 13:57 ` Joshua Lock
2017-02-08 19:36 ` Paul Eggleton
1 sibling, 0 replies; 9+ messages in thread
From: Joshua Lock @ 2017-02-08 13:57 UTC (permalink / raw)
To: Gary Thomas, yocto
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
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: sysroot question
2017-02-08 11:12 ` Gary Thomas
2017-02-08 13:57 ` Joshua Lock
@ 2017-02-08 19:36 ` Paul Eggleton
2017-02-09 4:23 ` Gary Thomas
1 sibling, 1 reply; 9+ messages in thread
From: Paul Eggleton @ 2017-02-08 19:36 UTC (permalink / raw)
To: Gary Thomas; +Cc: yocto
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
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: sysroot question
2017-02-08 19:36 ` Paul Eggleton
@ 2017-02-09 4:23 ` Gary Thomas
2017-02-09 7:49 ` Anders Darander
0 siblings, 1 reply; 9+ messages in thread
From: Gary Thomas @ 2017-02-09 4:23 UTC (permalink / raw)
To: yocto
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
------------------------------------------------------------
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: sysroot question
2017-02-09 4:23 ` Gary Thomas
@ 2017-02-09 7:49 ` Anders Darander
2017-02-09 8:04 ` Gary Thomas
0 siblings, 1 reply; 9+ messages in thread
From: Anders Darander @ 2017-02-09 7:49 UTC (permalink / raw)
To: yocto
* 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
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: sysroot question
2017-02-09 7:49 ` Anders Darander
@ 2017-02-09 8:04 ` Gary Thomas
0 siblings, 0 replies; 9+ messages in thread
From: Gary Thomas @ 2017-02-09 8:04 UTC (permalink / raw)
To: yocto
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
------------------------------------------------------------
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: sysroot question
2011-01-17 19:46 Zhang, Jessica
@ 2011-01-17 20:01 ` Mark Hatle
0 siblings, 0 replies; 9+ messages in thread
From: Mark Hatle @ 2011-01-17 20:01 UTC (permalink / raw)
To: poky
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
^ permalink raw reply [flat|nested] 9+ messages in thread
* sysroot question
@ 2011-01-17 19:46 Zhang, Jessica
2011-01-17 20:01 ` Mark Hatle
0 siblings, 1 reply; 9+ messages in thread
From: Zhang, Jessica @ 2011-01-17 19:46 UTC (permalink / raw)
To: Purdie, Richard; +Cc: poky
[-- 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 --]
^ permalink raw reply [flat|nested] 9+ messages in thread
end of thread, other threads:[~2017-02-09 8:05 UTC | newest]
Thread overview: 9+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2017-02-08 10:42 sysroot question Gary Thomas
2017-02-08 11:12 ` Gary Thomas
2017-02-08 13:57 ` Joshua Lock
2017-02-08 19:36 ` Paul Eggleton
2017-02-09 4:23 ` Gary Thomas
2017-02-09 7:49 ` Anders Darander
2017-02-09 8:04 ` Gary Thomas
-- strict thread matches above, loose matches on Subject: below --
2011-01-17 19:46 Zhang, Jessica
2011-01-17 20:01 ` Mark Hatle
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.