On 04/17/2013 06:24 PM, Bruce Ashfield wrote:
On Wed, Apr 17, 2013 at 10:05 AM, Sergey Matyukevich
<[email protected]> wrote:
Hello,
Suppose we build software for x86 targets on x86 build hosts. There are
use-cases
when it is not enough to specify x86 as a kernel architecture. It is
necessary
What are the details of the use cases ? I've never run into this myself,
and
almost no parts of the kernel build infrastructure differentiates between
x86 and x86_64 .. so I'm curious to know what is breaking.
So far we observed this problem in two cases:
- build systemtap modules for x86_32 target on x86_64 build hosts
- build virtualbox-guest modules for x86_32 target on x86_64 build hosts
I'm still interested in drilling down on the details. If the build of
those modules
is being influenced by the build host vs the target kernel, that's a form of
host contamination in my book.
i.e. so with this change you are setting TARGET_ARCH more precisely, but
that's going to impact the kernel build itself, and the current x86 is exactly
what other layers and recipes would expect, as does the kernel build.
With the more specific setting, clearly the builds of the modules you mention
make use of it, is it that they are currently seeing 'x86' and defaulting to
64 bit ? I'd expect that they could be patched to look at the staged kernel
source or the .config to determine something similar, and the change would
be more isolated. I'm guessing, since as I said, I haven't run into these myself
and haven't gone to crawl the code yet.
Adding a return value of i386 now is also a interesting, it currently
isn't returned,
and doesn't really mean anything useful to the kernel build anymore.
It's strictly
compatibility. Why doesn't a return of 'x86' work in any case that you are
returning i386 ?
Concerning your comments:
- host contamination
It doesn't seem to be a contamination by host settings. In the case of
systemtap modules, build failed for ARCH=x86, but was ok for ARCH=i386.
However note, that it was is not systemtap itself, it was a custom
systemtap probe module built by systemtap tools.
- i386 vs x86
As you noted, i386 does not mean anything really useful anymore from the
'kernel point of view'. Roughtly speaking, it is an alias for x86_32.
That is why it should not break any other layers and recipes which
expect x86. In other words, split i386-x86-x86_64 affects only those who
are interested in this information.
Sure, all the mentioned issues could be fixed in an isolated way in
their recipes. Though after I ran into the same type of issue twice, I
thought it might be reasonable to propagate the fix upstairs, to oe-core.
Thanks,
Sergey
_______________________________________________
Openembedded-core mailing list
[email protected]
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
