I think what I'm saying is that the whole ARCH thing is a linuxism that should not be popping up in a baremetal (or any other non-linux) configuration, and hacking map_kernel_arch() to return some benign-but-bogus value seems like the wrong fix for it. Particularly if this hacking is based on the value of TCLIBC which, conceptually, is not all that tightly bound to a kernel.
If there are places in the metadata that "inherit kernel-arch" in a non-linux-specific context then I think we should figure out some way to eliminate them. In the longer term I think it would make sense to have a "kernel" -> "linux" renaming to make these assumptions more explicit. p. On Wed, 2015-09-09 at 21:27 +0000, Bystricky, Juro wrote: > I would not call it a real bug. The code just tries to initialize ARCH > (which may not be used > for baremetal situations). The name "map_kernel_arch" is a bit misleading > in this (baremetal) context. > > > > -----Original Message----- > > From: Phil Blundell [mailto:[email protected]] > > Sent: Wednesday, September 9, 2015 2:21 AM > > To: Bystricky, Juro > > Cc: [email protected]; Purdie, Richard > > Subject: Re: [OE-core] [PATCH] kernel-arch.bbclass: Allow 'baremetal' CPUs > > > > On Tue, 2015-09-08 at 18:19 -0700, Juro Bystricky wrote: > > > Avoid "ERROR: cannot map <cpu> to a linux kernel architecture" > > > Not being able to map a CPU to a kernel architecture should not be > > > treated as an error when building baremetal toolchains for CPU <cpu> > > > which does not have a kernel source tree. > > > > Why is map_kernel_arch() even being invoked for a baremetal > > configuration? That sounds like it is the real bug here. > > > > p. > > > -- _______________________________________________ Openembedded-core mailing list [email protected] http://lists.openembedded.org/mailman/listinfo/openembedded-core
