Re: [yocto] Booting .hddimg from USB failed -> ramdisk not found /dev/ram0 - HELP!
Hi Nick, attached is my kernel .bbappend and .cfg files of linux kernel
recipe of my own layer. In original meta layer nothing was changed.
However, I spent last night trying to resolve the problem and found out
that standard core-sato-image was missing
meta/recipes-core/initrdscripts
I added that to the local.conf file and also added grub to it.
I wonder how 'install' was possible without those scripts, well, never mind.
After building .hddimg again i was able to boot and install the image from
USB device to atom-pc. Installation seemed to work without problems BUT
after removing the usb device, boot FAILED: *not bootable device* - I was
crying out loud, belive me!, gave up and went directly to bed...
The same(built and generated at the same bitbake run) iso image is working
in virtual box like a charm.
There must be a difference/bug somewhere.
Vbox is creating partitions on hda, atom-pc has sda. Should not be a
problem, but still a difference.
Could you help me on that? There are 3 Partitions on /dev/sda:
/dev/sda1 - boot partition (no asterix in partition table visible, but no
asterix on Vbox partition table as well)
/dev/sda2 - rootfs
/dev/sda3 - swap
However, I will open another thread for this.
thank you and best regards
simon:-)
On Fri, Jan 9, 2015 at 3:17 AM, nick wrote:
> Simon,
> Please send me your kernel bb recipes as there is probably an issue in
> them.
> Regards,
> Nick
>
> On 2015-01-08 03:58 PM, Simon Bolek wrote:
> > NIck, thank you. what do you mean by that? I followed the instructions
> from
> > here:
> >
> http://www.yoctoproject.org/docs/1.7/kernel-dev/kernel-dev.html#changing-the-configuration
> > is there something there I might be missing? Where is the part, 'linking
> > your kernels to the core-image-sato build' that you are talking about?
> >
> > thank you and best regards
> > simon:-)
> >
> > On Thu, Jan 8, 2015 at 6:50 PM, nick wrote:
> >
> >> Simon,
> >> Why are you not linking your kernels to the core-image-sato build.
> >> This seems to be the issue.
> >> Regards Nick
> >>
> >> On 2015-01-08 05:59 AM, Simon Bolek wrote:
> >>> Thank you Nick. I will try that, but this is not the point. I am trying
> >> to
> >>> figure out why
> >>> *bitbake core-image-sato *
> >>> does not create /dev/ram nodes, although linux-yocto has them defiined
> in
> >>> .config file.
> >>>
> >>> I also created:
> >>> mylayer/recipes-kernel/linux/linux_yocto_3.4.bbapend
> >>> mylayer/recipes-kernel/linux/linux_yocto_3.10.bbapend
> >>> mylayer/recipes-kernel/linux/linux_yocto_3.14.bbapend
> >>>
> >>> with the following content:
> >>>
> >>> FILESEXTRAPATHS_prepend := "${THISDIR}/files:"
> >>> SRC_URI += "file://ramdisk.cfg"
> >>>
> >>> and
> >>> mylayer/recipes-kernel/linux/files/ramdisk.cfg
> >>>
> >>> with content:
> >>> CONFIG_BLK_DEV_RAM=y
> >>> CONFIG_BLK_DEV_RAM_COUNT=16
> >>> CONFIG_BLK_DEV_RAM_SIZE=4096
> >>>
> >>> and afterwards run the commands:
> >>> bitbake linux-yocto -c cleansstate
> >>> bitbake linux-yocto
> >>> bitbake core-image-sato
> >>>
> >>> again. Same result, no /dev/ram nodes under rootfs.
> >>>
> >>> What am i doing wrong?
> >>>
> >>> thank you
> >>> simon:-)
> >>>
> >>> On Thu, Jan 8, 2015 at 2:03 AM, nick wrote:
> >>>
> Simon,
> Can you boot this on standard computer with qemu.
> Try that first and report back if that works.
> Nick
>
> On 2015-01-07 04:59 PM, Simon Bolek wrote:
> > Hello folks!
> >
> > I have the following problem/question.
> > 1) I built a standard .hddimg core-image-sato genericx86 on ubuntu
> >> 14.10
> > 2) Afterwards, this .hddimg was deployed to USB device (USB-ZIP
> method)
> > 3) Tried to boot Atom PC from the USB Device -> *ERROR: cound not
> found
> > ramdisk*
> >
> > so initrd is trying to find /dev/ram0 which does not exist in the
> >> image.
> I
> > checked rootfs and there is nothing under
> >
>
> >>
> ../poky/build/tmp/work/genericx86-poky-linux/core-image-sato/1.0-r0/rootfs/dev
> >
> > I googled this up and there is a thread telling to check the .config
> >> file
> > for *CONFIG_BLK_DEV_RAM *settings*.*
> > I have the following entries in:
> >
>
> >>
> ../poky/build/tmp/work/genericx86-poky-linux/linux-yocto/3.10.35+gitAUTOINC+7df9ef8ee4_2ee37bfe73-r0/linux-genericx86-standard-build/.config
> > ...
> > CONFIG_BLK_DEV_RAM=y
> > CONFIG_BLK_DEV_RAM_COUNT=16
> > CONFIG_BLK_DEV_RAM_SIZE=4096
> > ...
> >
> > I also *bitbake core-image-sato -c cleansstate* twice already.
> > I also* bitbake core-image-sato -c menuconfig *once more and
> > afterwards *bitbake
> > linux-yocto* again.
> > I also tried IRC channels, but no answer so far...
> >
> > Can anyone help me? How can i force bitbake to create /dev/ram0 under
> > rootfs?
> > Or maybe there is another trick to boot the image from USB?
> >
> > best regards
> > simon:-)
> >
> > Viele Grüsse
> > Simon Bo
[yocto] Atom-pc, usb installation - NO BOOTABLE DEVICE
Hi,
The following is the case:
1) atom-pc with ssd 80 GB hard drive(the only one, no optical, no usb,
etc.) as a target device
2) core-image-sato bitbaked and moved to usb device successfully
3) usb 'install' to atom-pc successfull (so the install script says)
4) after removing the usb device, pressing enter the boot says NO BOOTABLE
DEVICE
WHY?
At the same time, ISO image (generated at the same bitbake run) is working
in virtual box like a charm. 'Install' was successfull and booting fine - i
get GRUB menu with one 'Linux' entry as expected.
On the Atom-pc this is not working. So something has to be missing. Maybe
you will have a clue.
Here are the details:
The SSD HDD is /dev/sda with the partition table:
/dev/sda1 - boot
/dev/sda2 - rootfs
/dev/sda3 - swap
there is no asterix at boot partition
under /dev/sda1/grub there is grub.cfg with:
menuentry "Linux" {
set root=(hd0,1)
linux /vmlinux root=/dev/sda2 rw
}
- so first HDD, first/boot partition
- it points to /vmlinuz and /dev/sda2
It looks fine for me.
I already tried to dd if=/dev/zero of=/dev/sda bs=4M, and 'install' from
usb again, but no luck.
I already tried to put asterix on the boot partition, but than BOOT gets me
to *grub rescue>*
If you have any ideas, where to look for, please let me know.
thank you and best regards
simon :-)
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Atom-pc, usb installation - NO BOOTABLE DEVICE
On 01/09/2015 05:31 PM, Simon Bolek wrote:
Hi,
The following is the case:
1) atom-pc with ssd 80 GB hard drive(the only one, no optical, no usb,
etc.) as a target device
2) core-image-sato bitbaked and moved to usb device successfully
3) usb 'install' to atom-pc successfull (so the install script says)
4) after removing the usb device, pressing enter the boot says NO
BOOTABLE DEVICE
WHY?
The minimal installer in OE has the problem of hardcoding disk names in
grub configuration file instead of using UUID.
So it's possible that you may experience boot failures due to the change
of disk names.
//Chen Qi
At the same time, ISO image (generated at the same bitbake run) is
working in virtual box like a charm. 'Install' was successfull and
booting fine - i get GRUB menu with one 'Linux' entry as expected.
On the Atom-pc this is not working. So something has to be missing.
Maybe you will have a clue.
Here are the details:
The SSD HDD is /dev/sda with the partition table:
/dev/sda1 - boot
/dev/sda2 - rootfs
/dev/sda3 - swap
there is no asterix at boot partition
under /dev/sda1/grub there is grub.cfg with:
menuentry "Linux" {
set root=(hd0,1)
linux /vmlinux root=/dev/sda2 rw
}
- so first HDD, first/boot partition
- it points to /vmlinuz and /dev/sda2
It looks fine for me.
I already tried to dd if=/dev/zero of=/dev/sda bs=4M, and 'install'
from usb again, but no luck.
I already tried to put asterix on the boot partition, but than BOOT
gets me to /grub rescue>/
If you have any ideas, where to look for, please let me know.
thank you and best regards
simon :-)
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
[yocto] (no subject)
Hello, My yocto version is: 3.10.11-yocto-standard. I was trying to install git 1.8.1.2. While making git it is showing the following error: Writing MYMETA.yml GEN git-add--interactive make[2]: *** No rule to make target `/usr/lib/perl/5.14.3/CORE/config.h', needed by `perl.mak'. Stop. make[1]: *** [instlibdir] Error 2 make: *** [git-add--interactive] Error 2 I am unable to fix this. Any help regarding this will be highly appreciated. Thank you. Debasmita Lohar -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] Problems faced while installing git
Hello, My yocto version is: 3.10.11-yocto-standard. I was trying to install git 1.8.1.2. While making git it is showing the following error: Writing MYMETA.yml GEN git-add--interactive make[2]: *** No rule to make target `/usr/lib/perl/5.14.3/CORE/config.h', needed by `perl.mak'. Stop. make[1]: *** [instlibdir] Error 2 make: *** [git-add--interactive] Error 2 I am unable to fix this. Any help regarding this will be highly appreciated. Thank you. Debasmita Lohar MS Student Computer Science and Engineering IIT Kharagpur -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] do pkg_postinst() scripts need to start with "#!/bin/sh -e"?
more manual pedantry -- dev manual, section 5.3.16, suggests:
A post-installation function has the following structure:
pkg_postinst_PACKAGENAME() {
#!/bin/sh -e
# Commands to carry out
}
except that every example of a pkg_postinst() script i've ever seen
does not contain that initial hash-bang line, so the manual should at
least be reworded to be consistent with the code base.
rday
--
Robert P. J. Day Ottawa, Ontario, CANADA
http://crashcourse.ca
Twitter: http://twitter.com/rpjday
LinkedIn: http://ca.linkedin.com/in/rpjday
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] do pkg_postinst() scripts need to start with "#!/bin/sh -e"?
On Fri, 9 Jan 2015, Robert P. J. Day wrote:
>
> more manual pedantry -- dev manual, section 5.3.16, suggests:
>
> A post-installation function has the following structure:
>
> pkg_postinst_PACKAGENAME() {
> #!/bin/sh -e
> # Commands to carry out
> }
>
> except that every example of a pkg_postinst() script i've ever seen
> does not contain that initial hash-bang line, so the manual should
> at least be reworded to be consistent with the code base.
i take it back, i just ran across this example in base-passwd.bb:
pkg_postinst_${PN}-update () {
#!/bin/sh
if [ -n "$D" ]; then
exit 0
fi
${sbindir}/update-passwd
}
which (naturally) doesn't use the "-e" option :-). anyway, what does
one suggest for consistency across the manual and code base?
rday
--
Robert P. J. Day Ottawa, Ontario, CANADA
http://crashcourse.ca
Twitter: http://twitter.com/rpjday
LinkedIn: http://ca.linkedin.com/in/rpjday
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
[yocto] can't pull any sources anymore
Hi, I'm not able to pull any sources for a little time now. As test I re-tried an already working setup by again following some tutorial and trying to setup a fresh repo. The repo init works but the sync fails. I should mention that due to network limitations I replace git:// urls with https:// . Is it possible that this doesn't work anymore (I mean it is replaced but maybe the online repos don't support it anymore seamlessly)? Thanks Mat -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Bug reporting and good bug reports
[If I reply, people will think that I'm really big on this MAINTAINERS file thing, which I'm really not. But if I don't reply I'll feel as though my point was missed :-(] On 01/07/15 16:30, Richard Purdie wrote: > On Wed, 2015-01-07 at 16:21 -0500, Trevor Woerner wrote: >> On 01/07/15 04:25, Richard Purdie wrote: >>> I also have a patch. Where should I share them? How do I ensure everyone >>> with an interest in this defect actually gets the patch? Sure I can >>> create email and send to the people who I think need to know. >> When I went through that whole "let's add a MAINTAINERS file" thing last >> year this is exactly what I had in mind at that time. > But that isn't what I'm talking about. Okay, sorry for going off-topic. > I'm talking about people being able to say "I have some interest in a > particular defect and I'd like updates about it". That is completely > different to a MAINTAINERS file. The user and easily opt in to specific > things using the web UI and its self maintaining to a large degree. While, on the one hand, it would be nice for random people to say "I'm interested in this defect, I'm going to add myself to the list of people who are notified when something about this defect changes" (which, as I'm trying to point out, is a use-case of the MAINTAINERS file), I believe your more basic question of "I have a patch, who do I email it to?" needs to be addressed as well. At this point, we don't have much of a mechanism for people to figure out who to email their patches to. Emailing one's patches to the right people is a good thing since it'll increase the chances of it being reviewed by the most relevant people, and every project could stand to have more reviewers. What we have is a README file. But this mechanism requires people to read the README file (which isn't always a given) and follow its instructions (which is prone to various errors). The MAINTAINERS file automates the process of figuring out who the relevant people are to email your patches to. Not only can people add themselves to the list for a given area of the project, but the MAINTAINERS mechanism (i.e. the script) will also look at the git history of the lines your patch is modifying and add those people to the list as well (the assumption being the last person who modified the code you're about to modify might be interested in what you're doing to their code). Can you email your patch to bugzilla? And have bugzilla figure out all the people to forward your patch to? Not that I know of. Do you expect people working on a bug they find in the code one random day to go searching through bugzilla in case someone else has already noticed this bug and filed a report so they can look at the bugzilla issue's CC list to find out who to email the patch to? If a developer starts their day by looking through bugzilla for an open issue to fix (or is assigned such an issue from a manager) then your workflow makes sense. They will prepare a patch, update the issue, and then email the patch *hopefully* CC'ing the people in the bugzilla CC list and/or updating the issue with a link to their patch submission. But if a developer is working on their own thing and stumbles across some bug, completely unaware that this has been reported in bugzilla, they will prepare their patch and email it to the mailing list (and most likely nobody else). At least the MAINTAINERS file would help a little bit in this case (if for nothing else but to figure out which mailing list to email!) and if people added themselves to the MAINTAINERS file as being interested in a certain area, then those people would be emailed too. The biggest difference between what you're talking about and what I'm talking about is the granularity. A bugzilla entry addresses a defect, which could cross many files and layers. The granularity of the MAINTAINERS file is more about individual files and directories. Thanks for listening :-) -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] do pkg_postinst() scripts need to start with "#!/bin/sh -e"?
On 01/09/15 08:42, Robert P. J. Day wrote:
> On Fri, 9 Jan 2015, Robert P. J. Day wrote:
>
>> more manual pedantry -- dev manual, section 5.3.16, suggests:
>>
>> A post-installation function has the following structure:
>>
>> pkg_postinst_PACKAGENAME() {
>> #!/bin/sh -e
>> # Commands to carry out
>> }
>>
>> except that every example of a pkg_postinst() script i've ever seen
>> does not contain that initial hash-bang line, so the manual should
>> at least be reworded to be consistent with the code base.
> i take it back, i just ran across this example in base-passwd.bb:
>
> pkg_postinst_${PN}-update () {
> #!/bin/sh
> if [ -n "$D" ]; then
> exit 0
> fi
> ${sbindir}/update-passwd
> }
>
> which (naturally) doesn't use the "-e" option :-). anyway, what does
> one suggest for consistency across the manual and code base?
Let me be the first (of many, no doubt!) to suggest:
#!/bin/bash
*ducks* :-)
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
[yocto] [PATCH][yocto-docs] Update a couple recipes in dev manual.
Update listings of a couple recipes in section 5.3 to match current
source.
Signed-off-by: Robert P. J. Day
---
diff --git a/documentation/dev-manual/dev-manual-common-tasks.xml
b/documentation/dev-manual/dev-manual-common-tasks.xml
index 17d725b..611bb74 100644
--- a/documentation/dev-manual/dev-manual-common-tasks.xml
+++ b/documentation/dev-manual/dev-manual-common-tasks.xml
@@ -2867,6 +2867,7 @@
SRCREV = "9f107132a6a073cce37434ca9cda6917dd8d866b"
SRC_URI = "git://git.infradead.org/mtd-utils.git \
file://add-exclusion-to-mkfs-jffs2-git-2.patch \
+ file://fix-armv7-neon-alignment.patch \
"
PV = "1.5.1+git${SRCPV}"
@@ -2910,11 +2911,10 @@
require xorg-lib-common.inc
- SUMMARY = "X11 Pixmap library"
- LICENSE = "X-BSD"
- LIC_FILES_CHKSUM = "file://COPYING;md5=3e07763d16963c3af12db271a31abaa5"
+ SUMMARY = "Xpm: X Pixmap extension library"
+ LICENSE = "BSD"
+ LIC_FILES_CHKSUM = "file://COPYING;md5=51f4270b012ecd4ab1a164f5f4ed6cf7"
DEPENDS += "libxext libsm libxt"
- PR = "r3"
PE = "1"
XORG_PN = "libXpm"
--
Robert P. J. Day Ottawa, Ontario, CANADA
http://crashcourse.ca
Twitter: http://twitter.com/rpjday
LinkedIn: http://ca.linkedin.com/in/rpjday
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] can't pull any sources anymore
On 01/09/2015 06:10 AM, matthias.he...@atlas-elektronik.com wrote: Hi, I'm not able to pull any sources for a little time now. As test I re-tried an already working setup by again following some tutorial and trying to setup a fresh repo. The repo init works but the sync fails. I should mention that due to network limitations I replace git:// urls with https:// . Is it possible that this doesn't work anymore (I mean it is replaced but maybe the online repos don't support it anymore seamlessly)? Can you be more specific, are you talking about the git repos at git.yoctoproject.org or some other git source? You say a "repo init works", does that mean an initial clone or ? What commands are you running? I think a little more information is needed here. Sau! Thanks Mat -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Booting .hddimg from USB failed -> ramdisk not found /dev/ram0 - HELP!
Simon,
Your right is this probably an issue with your boot partition config.
Regards Nick
On 2015-01-09 04:20 AM, Simon Bolek wrote:
> Hi Nick, attached is my kernel .bbappend and .cfg files of linux kernel
> recipe of my own layer. In original meta layer nothing was changed.
>
> However, I spent last night trying to resolve the problem and found out
> that standard core-sato-image was missing
> meta/recipes-core/initrdscripts
> I added that to the local.conf file and also added grub to it.
> I wonder how 'install' was possible without those scripts, well, never mind.
> After building .hddimg again i was able to boot and install the image from
> USB device to atom-pc. Installation seemed to work without problems BUT
> after removing the usb device, boot FAILED: *not bootable device* - I was
> crying out loud, belive me!, gave up and went directly to bed...
>
> The same(built and generated at the same bitbake run) iso image is working
> in virtual box like a charm.
> There must be a difference/bug somewhere.
> Vbox is creating partitions on hda, atom-pc has sda. Should not be a
> problem, but still a difference.
> Could you help me on that? There are 3 Partitions on /dev/sda:
> /dev/sda1 - boot partition (no asterix in partition table visible, but no
> asterix on Vbox partition table as well)
> /dev/sda2 - rootfs
> /dev/sda3 - swap
>
> However, I will open another thread for this.
>
> thank you and best regards
> simon:-)
>
> On Fri, Jan 9, 2015 at 3:17 AM, nick wrote:
>
>> Simon,
>> Please send me your kernel bb recipes as there is probably an issue in
>> them.
>> Regards,
>> Nick
>>
>> On 2015-01-08 03:58 PM, Simon Bolek wrote:
>>> NIck, thank you. what do you mean by that? I followed the instructions
>> from
>>> here:
>>>
>> http://www.yoctoproject.org/docs/1.7/kernel-dev/kernel-dev.html#changing-the-configuration
>>> is there something there I might be missing? Where is the part, 'linking
>>> your kernels to the core-image-sato build' that you are talking about?
>>>
>>> thank you and best regards
>>> simon:-)
>>>
>>> On Thu, Jan 8, 2015 at 6:50 PM, nick wrote:
>>>
Simon,
Why are you not linking your kernels to the core-image-sato build.
This seems to be the issue.
Regards Nick
On 2015-01-08 05:59 AM, Simon Bolek wrote:
> Thank you Nick. I will try that, but this is not the point. I am trying
to
> figure out why
> *bitbake core-image-sato *
> does not create /dev/ram nodes, although linux-yocto has them defiined
>> in
> .config file.
>
> I also created:
> mylayer/recipes-kernel/linux/linux_yocto_3.4.bbapend
> mylayer/recipes-kernel/linux/linux_yocto_3.10.bbapend
> mylayer/recipes-kernel/linux/linux_yocto_3.14.bbapend
>
> with the following content:
>
> FILESEXTRAPATHS_prepend := "${THISDIR}/files:"
> SRC_URI += "file://ramdisk.cfg"
>
> and
> mylayer/recipes-kernel/linux/files/ramdisk.cfg
>
> with content:
> CONFIG_BLK_DEV_RAM=y
> CONFIG_BLK_DEV_RAM_COUNT=16
> CONFIG_BLK_DEV_RAM_SIZE=4096
>
> and afterwards run the commands:
> bitbake linux-yocto -c cleansstate
> bitbake linux-yocto
> bitbake core-image-sato
>
> again. Same result, no /dev/ram nodes under rootfs.
>
> What am i doing wrong?
>
> thank you
> simon:-)
>
> On Thu, Jan 8, 2015 at 2:03 AM, nick wrote:
>
>> Simon,
>> Can you boot this on standard computer with qemu.
>> Try that first and report back if that works.
>> Nick
>>
>> On 2015-01-07 04:59 PM, Simon Bolek wrote:
>>> Hello folks!
>>>
>>> I have the following problem/question.
>>> 1) I built a standard .hddimg core-image-sato genericx86 on ubuntu
14.10
>>> 2) Afterwards, this .hddimg was deployed to USB device (USB-ZIP
>> method)
>>> 3) Tried to boot Atom PC from the USB Device -> *ERROR: cound not
>> found
>>> ramdisk*
>>>
>>> so initrd is trying to find /dev/ram0 which does not exist in the
image.
>> I
>>> checked rootfs and there is nothing under
>>>
>>
>> ../poky/build/tmp/work/genericx86-poky-linux/core-image-sato/1.0-r0/rootfs/dev
>>>
>>> I googled this up and there is a thread telling to check the .config
file
>>> for *CONFIG_BLK_DEV_RAM *settings*.*
>>> I have the following entries in:
>>>
>>
>> ../poky/build/tmp/work/genericx86-poky-linux/linux-yocto/3.10.35+gitAUTOINC+7df9ef8ee4_2ee37bfe73-r0/linux-genericx86-standard-build/.config
>>> ...
>>> CONFIG_BLK_DEV_RAM=y
>>> CONFIG_BLK_DEV_RAM_COUNT=16
>>> CONFIG_BLK_DEV_RAM_SIZE=4096
>>> ...
>>>
>>> I also *bitbake core-image-sato -c cleansstate* twice already.
>>> I also* bitbake core-image-sato -c menuconfig *once more and
>>> afterwards *bitbake
>>> linux-yocto* again.
>>> I also tried IRC channels, but no answer so far...
>>>
>>> Can anyone help me? How can i for
[yocto] linux: having problems forcing a kernel recompile...
Hi, I'm working with the latest poky master branch (as of this morning: 876370419a), and I can't force a recompile of the kernel: $ bitbake virtual/kernel -c compile -f fails with | make[2]: *** [prepare3] Error 1 I have seen this with both linux-qoriq and my own derived linux-yocto recipe. I believe it's due to my sysroots kernel source directory not being clean. When I initially bake my kernel, I can see that the do_populate_sysroot task is run and it copies a .config into sysroots//usr/src/kernel. When I try to force the recompile, MAKE sees that my source directory isn't clean and quits ( throws the prepare3 error ). Somewhat related, I also notice that neither a $ bitbake virtual/kernel -c cleansstate nor a $ bitbake virtual/kernel -c cleanall actually cleans my kernel source directory. Should it? If these are legitimate bugs, I'll be happy to file a bugzilla report. Thanks Bob Error Log from running "bitbake virtual/kernel -c compile -f": | DEBUG: Executing shell function do_compile | NOTE: make -j 4 uImage CC=powerpc64-poky-linux-gcc --sysroot=/build/yocto/t1040_1/tmp/sysroots/t1040rdb-64b LD=powerpc64-poky-linux-ld.bfd --sysroot=/build/yocto/t1040_1/tmp/sysroots/t1040rdb-64b | CHK include/config/kernel.release | GEN /build/yocto/t1040_1/tmp/work/t1040rdb_64b-poky-linux/linux-qoriq/3.12-r0/build/Makefile | CHK include/generated/uapi/linux/version.h | Using /build/yocto/t1040_1/tmp/sysroots/t1040rdb-64b/usr/src/kernel as source for kernel | /build/yocto/t1040_1/tmp/sysroots/t1040rdb-64b/usr/src/kernel is not clean, please run 'make mrproper' | in the '/build/yocto/t1040_1/tmp/sysroots/t1040rdb-64b/usr/src/kernel' directory. | CHK include/generated/utsrelease.h | make[2]: *** [prepare3] Error 1 | make[2]: *** Waiting for unfinished jobs | CC scripts/mod/empty.o | CC scripts/mod/devicetable-offsets.s | MKELF scripts/mod/elfconfig.h | HOSTCC scripts/mod/modpost.o | HOSTCC scripts/mod/sumversion.o | GEN scripts/mod/devicetable-offsets.h | HOSTCC scripts/mod/file2alias.o | HOSTLD scripts/mod/modpost | make[1]: *** [sub-make] Error 2 | make: *** [all] Error 2 | ERROR: oe_runmake failed -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] admittedly simple questions about DISTRO_PN_ALIAS
(i'm in a proofreading mood today ...) reading dev manual here: http://www.yoctoproject.org/docs/1.7/dev-manual/dev-manual.html#usingpoky-configuring-DISTRO_PN_ALIAS and first silly question -- what is the *purpose* of that variable? as in, what effect will it have on the eventual image? what difference will it make that, say, in fedora, a recipe would produce a package with a slightly different name? that section doesn't really explain that, as far as i can tell. next, i can see the collection of those settings in the file meta-yocto/conf/distro/include/distro_alias.inc, which has some odd lines. for example: DISTRO_PN_ALIAS_pn-blktool = "Debian=blktool Mandriva=blktool" what's the value of defining an alleged alias that simply has the same name? what is happening here? oh, and there's this amusing example: DISTRO_PN_ALIAS_pn-bjam = "OpenSuSE=boost-jam Debina=bjam" ^^ but since the recipe name is the *same*, i'm guessing that doesn't cause a problem. finally, the dev manual doesn't explain the meaning of lines like: DISTRO_PN_ALIAS_pn-adt-installer = "Intel" DISTRO_PN_ALIAS_pn-alsa-state = "OE-Core" DISTRO_PN_ALIAS_pn-bdwgc = "OSPDT" in short, i can appreciate the *concept* of what might be happening in that short section, while still having no idea what value it has or how a developer might use it. rday -- Robert P. J. Day Ottawa, Ontario, CANADA http://crashcourse.ca Twitter: http://twitter.com/rpjday LinkedIn: http://ca.linkedin.com/in/rpjday -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] admittedly simple questions about DISTRO_PN_ALIAS
Hi Robert, On Friday 09 January 2015 12:19:32 Robert P. J. Day wrote: > reading dev manual here: > > http://www.yoctoproject.org/docs/1.7/dev-manual/dev-manual.html#usingpoky-co > nfiguring-DISTRO_PN_ALIAS > > and first silly question -- what is the *purpose* of that variable? as > in, what effect will it have on the eventual image? what difference > will it make that, say, in fedora, a recipe would produce a package > with a slightly different name? that section doesn't really explain > that, as far as i can tell. > > next, i can see the collection of those settings in the file > meta-yocto/conf/distro/include/distro_alias.inc, which has some odd > lines. for example: > > DISTRO_PN_ALIAS_pn-blktool = "Debian=blktool Mandriva=blktool" > > what's the value of defining an alleged alias that simply has the same > name? what is happening here? > > oh, and there's this amusing example: > > DISTRO_PN_ALIAS_pn-bjam = "OpenSuSE=boost-jam Debina=bjam" > ^^ > > but since the recipe name is the *same*, i'm guessing that doesn't > cause a problem. > > finally, the dev manual doesn't explain the meaning of lines like: > > DISTRO_PN_ALIAS_pn-adt-installer = "Intel" > DISTRO_PN_ALIAS_pn-alsa-state = "OE-Core" > DISTRO_PN_ALIAS_pn-bdwgc = "OSPDT" > > in short, i can appreciate the *concept* of what might be happening > in that short section, while still having no idea what value it has or > how a developer might use it. I'm not entirely sure how that section came to be written on its own, because it isn't at all useful and should probably be removed to save people confusion. DISTRO_PN_ALIAS is related to the mostly undocumented distrodata.bbclass that is supposed to help with managing recipe updates; I think the idea was to make a comparison with packages available in mainstream Linux distros but what it actually does for you in practice based on the code I can find doesn't seem to be very much. FYI, the reason distrodata has remained mostly undocumented is that we've had a plan to try to refactor and improve it for several years now, but it hasn't been as high a priority as we would have liked. There has been some renewed activity lately however - Aníbal Limón is working on the Recipe Reporting Service to replace what is up at packages.yoctoproject.org, and it should make it easier for people whose job it is to maintain recipes to track the current status with respect to upstream releases. It's being built on top of the OpenEmbedded Layer Index application. Cheers, Paul -- Paul Eggleton Intel Open Source Technology Centre -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] Error building meta-java openjdk-7 for ARM cortex-a7
Hello,
I have switched my git remote for meta-java from github.com/woglinde to
the one at yoctoproject.org to get the fix for the currency time expiry
issue along with other fixes and improvements.
I am encountering a problem building meta-java (openjdk-7) for
cortexa7hf-vfp-neon-poky-linux-gnueabi (Freescale Layerscape LS1021A)
It appears to be blowing up inside a task step that is run under QEMU
for ARM. Furthermore, it appears to be running QEMU as cortex-a8
whereas the Layerscape is a cortex-a7 (actually a dual core a7).
Generating assembler offsets
qemu-arm -cpu cortex-a8 -s 2097152 -L
/home/sierrawireless.local/dwatkins/workspace/epsilon/zeta_MG-os/build/tmp/sysroots/omg-zeta-ls1021atwr
-E
LD_LIBRARY_PATH=/home/sierrawireless.local/dwatkins/workspace/epsilon/zeta_MG-os/build/tmp/sysroots/omg-zeta-ls1021atwr/lib
./mkoffsets > offsets_arm.s
Generating ARM assembler bytecode sequences
arm-poky-linux-gnueabi-gcc -march=armv7-a -mthumb-interwork -mfloat-abi=hard
-mfpu=neon -mtune=cortex-a7
--sysroot=/home/sierrawireless.local/dwatkins/workspace/epsilon/zeta_MG-os/build/tmp/sysroots/omg-zeta-ls1021atwr
-DLINUX -D_GNU_SOURCE -DCC_INTERP -DZERO -DTARGET_ARCH_NYI_6939861=1 -DARM
-DZERO_LIBARCH=\"arm\" -DPRODUCT -I.
-I/home/sierrawireless.local/dwatkins/workspace/epsilon/zeta_MG-os/build/tmp/work/cortexa7hf-vfp-neon-poky-linux-gnueabi/openjdk-7-jre/25b30-2.3.12-r5.1/icedtea-2.3.12/build/openjdk/hotspot/src/share/vm/prims
-I/home/sierrawireless.local/dwatkins/workspace/epsilon/zeta_MG-os/build/tmp/work/cortexa7hf-vfp-neon-poky-linux-gnueabi/openjdk-7-jre/25b30-2.3.12-r5.1/icedtea-2.3.12/build/openjdk/hotspot/src/share/vm
-I/home/sierrawireless.local/dwatkins/workspace/epsilon/zeta_MG-os/build/tmp/work/cortexa7hf-vfp-neon-poky-linux-gnueabi/openjdk-7-jre/25b30-2.3.12-r5.1/icedtea-2.3.12/build/openjdk/hotspot/src/share/vm/precompiled
-I/home/sierrawireless.local/dw
atkins/workspace/epsilon/zeta_MG-os/build/tmp/work/cortexa7hf-vfp-neon-poky-linux-gnueabi/openjdk-7-jre/25b30-2.3.12-r5.1/icedtea-2.3.12/build/openjdk/hotspot/src/cpu/zero/vm
-I/home/sierrawireless.local/dwatkins/workspace/epsilon/zeta_MG-os/build/tmp/work/cortexa7hf-vfp-neon-poky-linux-gnueabi/openjdk-7-jre/25b30-2.3.12-r5.1/icedtea-2.3.12/build/openjdk/hotspot/src/os_cpu/linux_zero/vm
-I/home/sierrawireless.local/dwatkins/workspace/epsilon/zeta_MG-os/build/tmp/work/cortexa7hf-vfp-neon-poky-linux-gnueabi/openjdk-7-jre/25b30-2.3.12-r5.1/icedtea-2.3.12/build/openjdk/hotspot/src/os/linux/vm
-I/home/sierrawireless.local/dwatkins/workspace/epsilon/zeta_MG-os/build/tmp/work/cortexa7hf-vfp-neon-poky-linux-gnueabi/openjdk-7-jre/25b30-2.3.12-r5.1/icedtea-2.3.12/build/openjdk/hotspot/src/os/posix/vm
-I../generated -DHOTSPOT_RELEASE_VERSION="\"23.7-b01\""
-DHOTSPOT_BUILD_TARGET="\"product\""
-DHOTSPOT_BUILD_USER="\"dwatkins@sierrawireless.local\""
-DHOTSPOT_LIB_ARCH=\"arm\" -DHOTSPOT_
VM_DISTRO="\"OpenJDK\"" -O2 -pipe -g -feliminate-unused-debug-types
-DTARGET_OS_FAMILY_linux -DTARGET_ARCH_zero -DTARGET_ARCH_MODEL_zero
-DTARGET_OS_ARCH_linux_zero -DTARGET_OS_ARCH_MODEL_linux_zero
-DTARGET_COMPILER_gcc
-I/home/sierrawireless.local/dwatkins/workspace/epsilon/zeta_MG-os/build/tmp/sysroots/omg-zeta-ls1021atwr/usr/lib/libffi-3.0.13/include
-fno-rtti -fno-exceptions -D_REENTRANT -fcheck-new -fvisibility=hidden
-pipe -g -DTARGET_OS_FAMILY_linux -DTARGET_ARCH_zero -DTARGET_ARCH_MODEL_zero
-DTARGET_OS_ARCH_linux_zero -DTARGET_OS_ARCH_MODEL_linux_zero
-DTARGET_COMPILER_gcc
-I/home/sierrawireless.local/dwatkins/workspace/epsilon/zeta_MG-os/build/tmp/sysroots/omg-zeta-ls1021atwr/usr/lib/libffi-3.0.13/include
-fpic -fno-rtti -fno-exceptions -D_REENTRANT -fcheck-new -fvisibility=hidden
-pipe -g -O2 -pipe -g -feliminate-unused-debug-types -fno-strict-aliasing
-DHOTSPOT_ASM -DVM_LITTLE_ENDIAN -DINCLUDE_TRACE -Wpointer-arith
-Wsign-compare-E -x c++ - < /home/sie
rrawireless.local/dwatkins/workspace/epsilon/zeta_MG-os/build/tmp/work/cortexa7hf-vfp-neon-poky-linux-gnueabi/openjdk-7-jre/25b30-2.3.12-r5.1/icedtea-2.3.12/build/openjdk/hotspot/src/cpu/zero/vm/bytecodes_arm.def
| qemu-arm -cpu cortex-a8 -s 2097152 -L
/home/sierrawireless.local/dwatkins/workspace/epsilon/zeta_MG-os/build/tmp/sysroots/omg-zeta-ls1021atwr
-E
LD_LIBRARY_PATH=/home/sierrawireless.local/dwatkins/workspace/epsilon/zeta_MG-os/build/tmp/sysroots/omg-zeta-ls1021atwr/lib
./mkbc - bytecodes_arm.s
[ -f libjsig.so ] || { ln -s libjsig.so libjsig.so; }
/bin/sh: line 1: 29022 Done(2) arm-poky-linux-gnueabi-gcc
-march=armv7-a -mthumb-interwork -mfloat-abi=hard -mfpu=neon -mtune=cortex-a7
--sysroot=/home/sierrawireless.local/dwatkins/workspace/epsilon/zeta_MG-os/build/tmp/sysroots/omg-zeta-ls1021atwr
-DLINUX -D_GNU_SOURCE -DCC_INTERP -DZERO -DTARGET_ARCH_NYI_6939861=1 -DARM
-DZERO_LIBARCH=\"arm\" -DPRODUCT -I.
-I/home/sierrawireless.local/dwatkins/workspace/epsilon/zeta_MG-os/build/tmp/work/cortexa7hf-vfp-neon-poky-linux-gnueabi/openjd
[yocto] libtool woes
I'm trying to build a recipe which uses libtool. The problem I'm having is that the program uses glib-2.0 and one of the libraries from that package has library dependencies. This is giving libtool major troubles. I get errors like this: | sed: can't read =/usr/lib/libffi.la: No such file or directory | libtool: link: `=/usr/lib/libffi.la' is not a valid libtool archive This is coming from libgobject-2.0.la which contains this line: dependency_libs=' =/usr/lib/libglib-2.0.la -lpthread -L=/usr/lib =/usr/lib/libffi.la' The odd thing is that my recipe built the last time I tried, but admittedly that was in late 2013. Any ideas what I might be doing wrong or how to fix this? Thanks -- Gary Thomas | Consulting for the MLB Associates |Embedded world -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] libtool woes
On 1/9/15 12:26 PM, Gary Thomas wrote: > I'm trying to build a recipe which uses libtool. The problem > I'm having is that the program uses glib-2.0 and one of the > libraries from that package has library dependencies. This > is giving libtool major troubles. I get errors like this: >| sed: can't read =/usr/lib/libffi.la: No such file or directory >| libtool: link: `=/usr/lib/libffi.la' is not a valid libtool archive > > This is coming from libgobject-2.0.la which contains this line: >dependency_libs=' =/usr/lib/libglib-2.0.la -lpthread -L=/usr/lib > =/usr/lib/libffi.la' > > The odd thing is that my recipe built the last time I tried, > but admittedly that was in late 2013. > > Any ideas what I might be doing wrong or how to fix this? The version of libtool you are running doesn't understand cross compilation (sysroot) paths. (Sysroot paths start w/ the '='.) You should use "libtoolize" prior to running to update the libtool configuration to match the changes that OE/YP have. This works in almost all cases.. (where it doesn't work usually means someone had manually hacked on the previous libtool file...) --Mark > Thanks > -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] can't pull any sources anymore
On 01/09/2015 08:08 AM, Saul Wold wrote: > On 01/09/2015 06:10 AM, matthias.he...@atlas-elektronik.com wrote: >> Hi, >> >> I'm not able to pull any sources for a little time now. As test I >> re-tried an already working setup by again following some tutorial >> and trying to setup a fresh repo. The repo init works but the sync >> fails. I should mention that due to network limitations I replace >> git:// urls with https:// . Is it possible that this doesn't work >> anymore (I mean it is replaced but maybe the online repos don't >> support it anymore seamlessly)? Mat, Please note that the git:// and http:// URLs have a different structure. For example, git://git.yoctoproject.org/poky http://git.yoctoproject.org/git/poky https://git.yoctoproject.org/git/poky You can find these URLs at the bottom of any project page in cgit http://git.yoctoproject.org/cgit/cgit.cgi/poky/ Please try running "git clone https://git.yoctoproject.org/git/poky"; and if it fails send me the output. Thank you, Michael Halstead Yocto Project / SysAdmin > > Can you be more specific, are you talking about the git repos at > git.yoctoproject.org or some other git source? > > You say a "repo init works", does that mean an initial clone or ? > What commands are you running? > > I think a little more information is needed here. > > Sau! > >> Thanks >> >> Mat >> >> >> >> signature.asc Description: OpenPGP digital signature -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] libtool woes
On 2015-01-09 11:57, Mark Hatle wrote: On 1/9/15 12:26 PM, Gary Thomas wrote: I'm trying to build a recipe which uses libtool. The problem I'm having is that the program uses glib-2.0 and one of the libraries from that package has library dependencies. This is giving libtool major troubles. I get errors like this: | sed: can't read =/usr/lib/libffi.la: No such file or directory | libtool: link: `=/usr/lib/libffi.la' is not a valid libtool archive This is coming from libgobject-2.0.la which contains this line: dependency_libs=' =/usr/lib/libglib-2.0.la -lpthread -L=/usr/lib =/usr/lib/libffi.la' The odd thing is that my recipe built the last time I tried, but admittedly that was in late 2013. Any ideas what I might be doing wrong or how to fix this? The version of libtool you are running doesn't understand cross compilation (sysroot) paths. (Sysroot paths start w/ the '='.) You should use "libtoolize" prior to running to update the libtool configuration to match the changes that OE/YP have. This works in almost all cases.. (where it doesn't work usually means someone had manually hacked on the previous libtool file...) Thanks, that fixed it. -- Gary Thomas | Consulting for the MLB Associates |Embedded world -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] runqemu-extract-sdk does not provide all required librariesin rootfs
Hi Mihail, I originally installed poky 1.6.1 but when it generates the toolchain files it calls it them 1.6.2. The base image I am using is not core-image-sato-sdk as I was wanting to develop against my actual image and also test things directly on my target. My core image is supplied by the vendor (atmel-qt5-demo-image).In my config file i have added dbg-pkgs, dev-pkgs, eglibc-static. Adding eglib-static adds the libc's required. but I am still missing crtbegin.o, crtend.o, libgcc.a, and libgcc_s.so. Are there any images features that I can add to add these extra libraries? I can always test my applications on the qemuarm environment created by ADT as that has all the libraries/files required, but it is much faster to test on the target hardware and I need these packages in my sdk setup for the linker to create the object file for deployment on the target. Also that target has the hardware I need to test. The process I use at present it to: $ bitbake image (with above mentioned image extra features)$ bitbake image -c populate_sdk$ run the created shell script from the populate sdk to create toolchain in a directory X$ runqemu-extract-sdk on image-rootfs.tar.gz to create rootfs in directory Y$ copy from directory X to directory Y the files crtbegin.o, crtend.o, libgcc.a, and libgcc_s.so If there is something I am missing, please let me know. I would like the 4 files to be part of the rootfs when i create it. thanks for your helpLachlan - Original Message - From: "Mihail StanciuX" To:"peterengcomau...@adam.com.au" , "yocto@yoctoproject.org" Cc: Sent:Tue, 6 Jan 2015 09:23:15 + Subject:RE: [yocto] runqemu-extract-sdk does not provide all required libraries in rootfs Hi Lachlan, I just tried this on the “daisy” branch and I can find all the libraries you mention as being missing. Are you using core-image-sato-sdk as the “base” image? As far as I know 1.6.2 hasn’t been released yet, so what commit are you using? Regards, Mihail FROM: yocto-boun...@yoctoproject.org [mailto:yocto-boun...@yoctoproject.org] ON BEHALF OF peterengcomau...@adam.com.au SENT: Sunday, December 21, 2014 4:54 PM TO: yocto@yoctoproject.org SUBJECT: [yocto] runqemu-extract-sdk does not provide all required libraries in rootfs I am using poky 1.6.2. I am using the build chain created using $bitbake meta-ide-support. If I create a rootfs using ADT I can use Eclipse to test against qemu all OK but this is not the target rootfs so its use is limited If I create a rootfs using $ bitbake image -c populate_sdk then run the shell script, the rootfs created has all the required libraries, but it does not create a directory called pseudo_state, and qemu fails to work because of this. If I create a rootfs with runqemu-extract-sdk on the image I created using $ bitabke image, the resulting rootfs has the required pseudo_state directory but is missing crucial libraries. The missing libraries are crt1.o, crti.o, ctrn.o, crtbegin.o, crtend.o, crtn.o, libc.so, libc_nonshared.a, libgcc.a, libgcc_s.so, libgcc_s.so.1. I can import these libraries from the rootfs created by running the populate_sdk script, but I get many errors. The first errors indicate it cannot find stdio.h. I have attached the config.log file. There are so many errors but some one may be able to infer something from it. It seems to me that I am missing a setting when I execute 'runqemu-extract-sdk' otherwise all the required libraries would be there and I wouldnt get a compatibility issue with libraries created from a separate process (but same source). Can anyonee indicate where I should look to understand why runqemu-extract-sdk is not building all of the required libraries , or how I can overcome the problem ? Thank You Lachlan Message sent via Adam Internet WebMail - http://www.adam.com.au/ [1] Message sent via Adam Internet WebMail - http://www.adam.com.au/ Links: -- [1] http://www.adam.com.au/ -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Atom-pc, usb installation - NO BOOTABLE DEVICE
On 9 Jan 2015, at 09:31, Simon Bolek wrote:
> Hi,
>
> The following is the case:
> 1) atom-pc with ssd 80 GB hard drive(the only one, no optical, no usb, etc.)
> as a target device
> 2) core-image-sato bitbaked and moved to usb device successfully
> 3) usb 'install' to atom-pc successfull (so the install script says)
> 4) after removing the usb device, pressing enter the boot says NO BOOTABLE
> DEVICE
I've seen this is the past with an eSata device. Changing the BIOS emulation
mode for the device fixed it - I can't remember exactly what I had to do, but I
think I needed to set it to "IDE" mode to get the install to work (it would
then boot using either mode).
> WHY?
>
> At the same time, ISO image (generated at the same bitbake run) is working in
> virtual box like a charm. 'Install' was successfull and booting fine - i get
> GRUB menu with one 'Linux' entry as expected.
>
> On the Atom-pc this is not working. So something has to be missing. Maybe you
> will have a clue.
> Here are the details:
> The SSD HDD is /dev/sda with the partition table:
> /dev/sda1 - boot
> /dev/sda2 - rootfs
> /dev/sda3 - swap
> there is no asterix at boot partition
>
> under /dev/sda1/grub there is grub.cfg with:
> menuentry "Linux" {
>set root=(hd0,1)
>linux /vmlinux root=/dev/sda2 rw
> }
> - so first HDD, first/boot partition
> - it points to /vmlinuz and /dev/sda2
> It looks fine for me.
> I already tried to dd if=/dev/zero of=/dev/sda bs=4M, and 'install' from usb
> again, but no luck.
> I already tried to put asterix on the boot partition, but than BOOT gets me
> to grub rescue>
>
> If you have any ideas, where to look for, please let me know.
>
> thank you and best regards
> simon :-)
> --
> ___
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto
--
Chris Tapp
opensou...@keylevel.com
www.keylevel.com
You can tell you're getting older when your car insurance gets real cheap!
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] libm implementation issue
Hi Richard,I am using the standard poky DISTRO (although the
configuration is DISTRO ?= "poky' so something else my be changing
it. Also The final image is pretty large taking 256Mb.Is there
anything else I can check that may be altering the DISTRO or the
libc. If I look at all the setting in ECLIPSE, there is no reference
to changing any libm or -lm settings.
I am also having problems with some of the libraries being generated
when i use qemu-extra-sdk are not present in the resulting rootfs, so
I have to also run "$bitbake image -c populate_sdk" and manully copy
over the affected libraries. However, since I use eglibc-static in
the extra image features in the config file, I have not had a problem
with missing libc libraries according to the linker, but that doesn't
mean there is not something else wrong.
Also, I have been trying to access the jiffy.h which should be
standard in Linux but is not created as part of the build. It is
created during the build but something is removing it from the image
(or not including it). Do you have any idea what I can do to add
jiffy to the final image?
Thanks for your help.
Lachlan
- Original Message -
From: "Richard Purdie"
To:
Cc:
Sent:Wed, 31 Dec 2014 09:41:33 +
Subject:Re: [yocto] libm implementation issue
On Tue, 2014-12-30 at 20:09 +1030, peterengcomau...@adam.com.au
wrote:
>
> I have some software that uses specific mathematical functions.
When I
> attempt to compile them with the Yocto cross-compile tools, the
> functions are not recognised. E.g. 'pow' in
> According to website
https://wiki.yoctoproject.org/wiki/Minimal_Image,
> not all eglibc features are installed as standard, and that I
should
> alter my local.conf file. I have added the following:
>
> DISTRO_FEATURES_LIBC += " libc-libm "
> DISTRO_FEATURES_append = " ${DISTRO_FEATURES_LIBC} "
By default the libc we build is fully featured. The only time we cut
down the libc by default is when you use DISTRO = "poky-tiny". Are
you
using poky-tiny?
If you're not, the most likely issue you didn't see pow and friends
would be a missing linkage against libm (-lm on the commandline for
gcc/ld).
Cheers,
Richard
Message sent via Adam Internet WebMail - http://www.adam.com.au/
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
[yocto] yocto mailing list
pls subscribe me to the mailing list Sent from my iPhone -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
