All of lore.kernel.org
 help / color / mirror / Atom feed
From: Saul Wold <sgw@linux.intel.com>
To: Frans Meulenbroeks <fransmeulenbroeks@gmail.com>
Cc: yocto@yoctoproject.org,
	openembedded-devel <openembedded-devel@lists.openembedded.org>
Subject: Re: [yocto] yocto 1.2: 2nd experiences: image building problems
Date: Thu, 03 May 2012 11:16:30 -0700	[thread overview]
Message-ID: <4FA2CB7E.7080600@linux.intel.com> (raw)
In-Reply-To: <CACW_hTb5BO+mS07Xnd534N5V-ETtwrXc=NNo67kxcemQPGuJog@mail.gmail.com>

On 05/03/2012 01:01 AM, Frans Meulenbroeks wrote:
> Dear all,
>
> I'm migrating a project from oe-classic to yocto 1.2.
> This goes fairly smoothly. Got some warnings I reported before.
>
> If I build my app it runs fine (with the uclibc from oe-classic that
> is already on the board).
> Next step was to try to build a complete image.
>
> There I encountered two issues.
> The first one was that my image recipe had a few SRC_URI += lines.
> This to get the static device table I am using and two files I needed
> in my IMAGE_POSTPRCESS_COMMAND.
> However yocto immediately goes into do_rootfs, and does not have a
> fetch/unpack step (as oe-classic used to have).
>
> I have worked around this by adding
>
> python do_get_src () {
>      bb.build.exec_func('base_do_fetch', d)
>      bb.build.exec_func('base_do_unpack', d)
> }
> addtask do_get_src before do_rootfs
>
> to my image recipe. I think it would be nice to have this
> automatically done if a non-empty SRC_URI is found (but unfortunately
> I am not enough of a python wiz to provide a patch).
> Anyway that kept me moving.
>
Can you file a enhancement bug for the above issue.

> The second issue is probably lib related. As I need a small footprint
> (not too much storage available) my project uses uclibc.
> When building the image I get some 15 or so of these:
> | 	rtld(GNU_HASH) is needed by busybox-1.19.4-r6.ppce300c3
> | 	rtld(GNU_HASH) is needed by i2c-tools-3.0.3-r0.ppce300c3
> | 	rtld(GNU_HASH) is needed by libz1-1.2.6-r1.ppce300c3
> ...
>
> I noticed that eglibc has this:
> meta/recipes-core/eglibc/eglibc-package.inc:RPROVIDES_${PN} =
> "glibc${PKGSUFFIX} rtld(GNU_HASH)"
>
> but I did not find a similar RPROVIDES for uclibc.
> Not sure whether it is missing there, or whether the dependencies for
> the packages like busybox and libz1 are wrong.
> Anyone any advice ?
>
Khem might be able to help with this maybe.

Thanks
	Sau!

> Thanks, Frans
> _______________________________________________
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto
>
>



WARNING: multiple messages have this Message-ID (diff)
From: Saul Wold <sgw@linux.intel.com>
To: Frans Meulenbroeks <fransmeulenbroeks@gmail.com>
Cc: yocto@yoctoproject.org,
	openembedded-devel <openembedded-devel@lists.openembedded.org>
Subject: Re: yocto 1.2: 2nd experiences: image building problems
Date: Thu, 03 May 2012 11:16:30 -0700	[thread overview]
Message-ID: <4FA2CB7E.7080600@linux.intel.com> (raw)
In-Reply-To: <CACW_hTb5BO+mS07Xnd534N5V-ETtwrXc=NNo67kxcemQPGuJog@mail.gmail.com>

On 05/03/2012 01:01 AM, Frans Meulenbroeks wrote:
> Dear all,
>
> I'm migrating a project from oe-classic to yocto 1.2.
> This goes fairly smoothly. Got some warnings I reported before.
>
> If I build my app it runs fine (with the uclibc from oe-classic that
> is already on the board).
> Next step was to try to build a complete image.
>
> There I encountered two issues.
> The first one was that my image recipe had a few SRC_URI += lines.
> This to get the static device table I am using and two files I needed
> in my IMAGE_POSTPRCESS_COMMAND.
> However yocto immediately goes into do_rootfs, and does not have a
> fetch/unpack step (as oe-classic used to have).
>
> I have worked around this by adding
>
> python do_get_src () {
>      bb.build.exec_func('base_do_fetch', d)
>      bb.build.exec_func('base_do_unpack', d)
> }
> addtask do_get_src before do_rootfs
>
> to my image recipe. I think it would be nice to have this
> automatically done if a non-empty SRC_URI is found (but unfortunately
> I am not enough of a python wiz to provide a patch).
> Anyway that kept me moving.
>
Can you file a enhancement bug for the above issue.

> The second issue is probably lib related. As I need a small footprint
> (not too much storage available) my project uses uclibc.
> When building the image I get some 15 or so of these:
> | 	rtld(GNU_HASH) is needed by busybox-1.19.4-r6.ppce300c3
> | 	rtld(GNU_HASH) is needed by i2c-tools-3.0.3-r0.ppce300c3
> | 	rtld(GNU_HASH) is needed by libz1-1.2.6-r1.ppce300c3
> ...
>
> I noticed that eglibc has this:
> meta/recipes-core/eglibc/eglibc-package.inc:RPROVIDES_${PN} =
> "glibc${PKGSUFFIX} rtld(GNU_HASH)"
>
> but I did not find a similar RPROVIDES for uclibc.
> Not sure whether it is missing there, or whether the dependencies for
> the packages like busybox and libz1 are wrong.
> Anyone any advice ?
>
Khem might be able to help with this maybe.

Thanks
	Sau!

> Thanks, Frans
> _______________________________________________
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto
>
>


  reply	other threads:[~2012-05-03 18:26 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-05-03  8:01 yocto 1.2: 2nd experiences: image building problems Frans Meulenbroeks
2012-05-03 18:16 ` Saul Wold [this message]
2012-05-03 18:16   ` Saul Wold

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4FA2CB7E.7080600@linux.intel.com \
    --to=sgw@linux.intel.com \
    --cc=fransmeulenbroeks@gmail.com \
    --cc=openembedded-devel@lists.openembedded.org \
    --cc=yocto@yoctoproject.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
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.