All of lore.kernel.org
 help / color / mirror / Atom feed
From: Mark Hatle <mark.hatle@windriver.com>
To: <openembedded-core@lists.openembedded.org>
Subject: Re: [PATCH] Refuse to run bitbake on a kernel that is too old.
Date: Wed, 22 Oct 2014 18:49:19 +0800	[thread overview]
Message-ID: <54478BAF.7040307@windriver.com> (raw)
In-Reply-To: <ly7fzteo3p.fsf@ensc-virt.intern.sigma-chemnitz.de>

On 10/21/14, 6:03 PM, Enrico Scholz wrote:
> <jeffrey.honig-CWA4WttNNZF54TAoqtyWWQ@public.gmane.org> writes:
>
>> Bitbake.conf now specifies OLDEST_KERNEL to insure that the SDK is
>> not run on a kernel that is not supported by a component of the SDK
>> (i.e. glibc).
>
> OLDEST_KERNEL is used in glibc recipe only; it would be much better
> to build SDK's glibc with an --enable-kernel matching the target
> distribution.  E.g. by setting a special 'OLDEST_KERNEL_nativesdk'
> variable.

glibc included with master has a minimum kernel version due to various ABIs that 
it uses.  My understanding is that the OLDEST_KERNEL does indeed match for the 
nativesdk.

>> +    # Check that our kernel will work for crosssdk
>
> This check should be made overridable for environments which do not
> build SDKs.

Using the buildtools-tarball will result in these issues.. (that is a lot more 
common, at least for us due to the wide variety of distributions that don't have 
minimum tool versions...)

>> +    if os.uname()[0] == "Linux" and LooseVersion(os.uname()[2]) < LooseVersion(d.getVar('OLDEST_KERNEL')):
>
> This check does not work when you build e.g. in an LXC container.  You
> could define something like
>
> | SDK_UNAME ??= "${@' '.join(os.uname())}"
>
> and do the checks on this.
>
>
> Enrico
>



      reply	other threads:[~2014-10-22 10:49 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-10-20 18:30 [PATCH] Refuse to run bitbake on a kernel that is too old jeffrey.honig
2014-10-20 19:08 ` Burton, Ross
2014-10-20 23:30   ` Mark Hatle
2014-10-21 10:03 ` Enrico Scholz
2014-10-22 10:49   ` Mark Hatle [this message]

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=54478BAF.7040307@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.