From: Mark Hatle <mark.hatle@windriver.com>
To: <openembedded-core@lists.openembedded.org>
Subject: Re: static busybox?
Date: Tue, 31 Jul 2012 15:01:10 -0500 [thread overview]
Message-ID: <50183986.1030203@windriver.com> (raw)
In-Reply-To: <CAEsOVNeJxw0VbwPX+90riJeVzTQYLdR7dCp==TiCj+eCe=eExw@mail.gmail.com>
On 7/31/12 2:36 PM, McClintock Matthew-B29882 wrote:
> On Tue, Jul 31, 2012 at 1:14 PM, Stuart Yoder <b08248@gmail.com> wrote:
>> We are doing some work with LXC (containers) and one of the templates
>> is for busybox. For LXC, the busybox package needs to be built statically and
>> there is a config option for this.
>>
>> A couple possible approaches:
>>
>> -create a new 'busybox_static' recipe that the lxc package
>> depends on that turns on the needed build options. Pretty
>> straightforward, but now there are 2 variants of the busybox
>> package.
>
> This would seem to work OK with RDEPENDS += "busybox-static" and just
> adding the extra static bits for for the static version. It seems OK
> except we would/could start to get lots of recipes like this.
>
>> -somehow propagate some configuration options through to
>> the standard busybox recipe so it turns on the config
>> option to build things statically. Not sure how to
>> do this, and seems like it could get pretty messy.
>
> Are there any mechanism that currently exist for this? We could turn
> on a DISTRO_FEATURE if we knew we were going use lxc, but that's more
> involved than just adding the lxc recipe and getting the right stuff
> in the root file system.
Kernel config fragment mechanism is there and IMHO works well for something like
this, assuming configuration is using standard
FOO = value
# FOO is not set
kernel semantics....
> Does anyone else have any thoughts on the best approach here?
In this case, I don't think it's a distro feature, it's really a package
configuration option -- the assumption is the rest of the system isn't
statically linked. (Our case was that we wanted a static busybox for an initrd...)
> -M
>
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
>
next prev parent reply other threads:[~2012-07-31 20:12 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-07-31 18:14 static busybox? Stuart Yoder
2012-07-31 19:36 ` McClintock Matthew-B29882
2012-07-31 20:01 ` Mark Hatle [this message]
2012-08-01 16:48 ` Darren Hart
2012-07-31 19:59 ` Mark Hatle
2012-07-31 20:02 ` Jack Mitchell
2012-07-31 20:07 ` Bruce Ashfield
2012-08-01 16:21 ` Stuart Yoder
2012-08-01 16:36 ` Mark Hatle
2012-08-01 16:49 ` Darren Hart
2012-08-01 16:52 ` Bruce Ashfield
2012-08-01 18:59 ` McClintock Matthew-B29882
2012-08-01 19:05 ` Mark Hatle
2012-08-01 20:05 ` Otavio Salvador
2012-08-02 22:50 ` Stuart Yoder
2012-08-03 10:20 ` Koen Kooi
2012-08-03 11:19 ` Otavio Salvador
2012-08-03 15:30 ` Mark Hatle
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=50183986.1030203@windriver.com \
--to=mark.hatle@windriver.com \
--cc=openembedded-core@lists.openembedded.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.