* [PATCH] native.bbclass: add (re)definitions for TARGET_SYS and HOST_SYS
@ 2010-08-20 14:19 Frans Meulenbroeks
2010-08-20 14:39 ` Phil Blundell
0 siblings, 1 reply; 6+ messages in thread
From: Frans Meulenbroeks @ 2010-08-20 14:19 UTC (permalink / raw)
To: openembedded-devel
Signed-off-by: Frans Meulenbroeks <fransmeulenbroeks@gmail.com>
---
The issue at hand was discovered by setting
TARGET_OS_local = "linux-gnuspe"
in my local.conf file as I needed to build for ppc e500
This caused configure of gmp-native to be called with
--build=x86_64-linux --host=x86_64-linux --target=x86_64-linux-gnuspe
which in turn caused configure to fail.
The odd thing is that for a native recipe I would expect
that build host and target gets the same args.
The configure line comes from autotools.bbclass
which says:
CONFIGUREOPTS = " --build=${BUILD_SYS} \
--host=${HOST_SYS} \
--target=${TARGET_SYS} \
Apparently HOST_SYS and TARGET_SYS are not identical for native recipes
Peeking into native.bbclass learned that things like TARGET_PREFIX and
HOST_PREFIX are redefined, but TARGET_SYS and HOST_SYS are not.
This patch adds assignments to fix this.
I have tested this by building the image I am working on
(which includes some low level stuff like kernel and u-boot, and
also requires that lots of native recipes are build)
No problem was detected during that test.
If TARGET_OS = "linux" this will not make any difference for you.
If your TARGET_OS = "linux-gnuspe" like it is for me and your
build system has "linux" as OS, a side effect of this change
is that a rebuild is needed as the work dir will change
from (in my case) x68_64-linux to x86_64-linux-gnuspe
It might be that a full rebuild is needed in that case
(haven't tested that case)
Frans
classes/native.bbclass | 2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/classes/native.bbclass b/classes/native.bbclass
index 3437836..85c7cf1 100644
--- a/classes/native.bbclass
+++ b/classes/native.bbclass
@@ -23,6 +23,7 @@ TARGET_VENDOR = "${BUILD_VENDOR}"
TARGET_PREFIX = "${BUILD_PREFIX}"
TARGET_CC_ARCH = "${BUILD_CC_ARCH}"
TARGET_EXEEXT = "${BUILD_EXEEXT}"
+TARGET_SYS = "${BUILD_SYS}"
HOST_ARCH = "${BUILD_ARCH}"
HOST_OS = "${BUILD_OS}"
@@ -30,6 +31,7 @@ HOST_VENDOR = "${BUILD_VENDOR}"
HOST_PREFIX = "${BUILD_PREFIX}"
HOST_CC_ARCH = "${BUILD_CC_ARCH}"
HOST_EXEEXT = "${BUILD_EXEEXT}"
+HOST_SYS = "${BUILD_SYS}"
CPPFLAGS = "${BUILD_CPPFLAGS}"
CFLAGS = "${BUILD_CFLAGS}"
--
1.7.0.4
^ permalink raw reply related [flat|nested] 6+ messages in thread* Re: [PATCH] native.bbclass: add (re)definitions for TARGET_SYS and HOST_SYS 2010-08-20 14:19 [PATCH] native.bbclass: add (re)definitions for TARGET_SYS and HOST_SYS Frans Meulenbroeks @ 2010-08-20 14:39 ` Phil Blundell 2010-08-20 15:34 ` Khem Raj 0 siblings, 1 reply; 6+ messages in thread From: Phil Blundell @ 2010-08-20 14:39 UTC (permalink / raw) To: openembedded-devel On Fri, 2010-08-20 at 16:19 +0200, Frans Meulenbroeks wrote: > @@ -23,6 +23,7 @@ TARGET_VENDOR = "${BUILD_VENDOR}" > TARGET_PREFIX = "${BUILD_PREFIX}" > TARGET_CC_ARCH = "${BUILD_CC_ARCH}" > TARGET_EXEEXT = "${BUILD_EXEEXT}" > +TARGET_SYS = "${BUILD_SYS}" I don't think this is the right thing; native.bbclass already assigns TARGET_OS = "${BUILD_OS}". Do you really need to use a _local override for TARGET_OS? If so then I guess you need to find a way to stop it applying for virtclass-native. p. ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH] native.bbclass: add (re)definitions for TARGET_SYS and HOST_SYS 2010-08-20 14:39 ` Phil Blundell @ 2010-08-20 15:34 ` Khem Raj 2010-08-20 15:44 ` Khem Raj 0 siblings, 1 reply; 6+ messages in thread From: Khem Raj @ 2010-08-20 15:34 UTC (permalink / raw) To: openembedded-devel On Fri, Aug 20, 2010 at 7:39 AM, Phil Blundell <philb@gnu.org> wrote: > On Fri, 2010-08-20 at 16:19 +0200, Frans Meulenbroeks wrote: >> @@ -23,6 +23,7 @@ TARGET_VENDOR = "${BUILD_VENDOR}" >> TARGET_PREFIX = "${BUILD_PREFIX}" >> TARGET_CC_ARCH = "${BUILD_CC_ARCH}" >> TARGET_EXEEXT = "${BUILD_EXEEXT}" >> +TARGET_SYS = "${BUILD_SYS}" bitbake.conf already has TARGET_SYS=${TARGET_ARCH}${TARGET_VENDOR}${@['-' + bb.data.getVar('TARGET_OS', d, 1), ''][bb.data.getVar('TARGET_OS', d, 1) == ('' or 'custom')]} so once you have TARGET_OS set correctly this should work well for native too. > > I don't think this is the right thing; native.bbclass already assigns > TARGET_OS = "${BUILD_OS}". > > Do you really need to use a _local override for TARGET_OS? If so then I > guess you need to find a way to stop it applying for virtclass-native. > > p. > > > > _______________________________________________ > Openembedded-devel mailing list > Openembedded-devel@lists.openembedded.org > http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel > ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH] native.bbclass: add (re)definitions for TARGET_SYS and HOST_SYS 2010-08-20 15:34 ` Khem Raj @ 2010-08-20 15:44 ` Khem Raj 2010-08-20 16:48 ` Frans Meulenbroeks 0 siblings, 1 reply; 6+ messages in thread From: Khem Raj @ 2010-08-20 15:44 UTC (permalink / raw) To: openembedded-devel On Fri, Aug 20, 2010 at 8:34 AM, Khem Raj <raj.khem@gmail.com> wrote: > On Fri, Aug 20, 2010 at 7:39 AM, Phil Blundell <philb@gnu.org> wrote: >> On Fri, 2010-08-20 at 16:19 +0200, Frans Meulenbroeks wrote: >>> @@ -23,6 +23,7 @@ TARGET_VENDOR = "${BUILD_VENDOR}" >>> TARGET_PREFIX = "${BUILD_PREFIX}" >>> TARGET_CC_ARCH = "${BUILD_CC_ARCH}" >>> TARGET_EXEEXT = "${BUILD_EXEEXT}" >>> +TARGET_SYS = "${BUILD_SYS}" > > bitbake.conf already has > > TARGET_SYS=${TARGET_ARCH}${TARGET_VENDOR}${@['-' + > bb.data.getVar('TARGET_OS', d, 1), ''][bb.data.getVar('TARGET_OS', d, > 1) == ('' or 'custom')]} > > so once you have TARGET_OS set correctly this should work well for native too. hmm _local ok if you override TARGET_OS locally then lot of other things will change because now TARGET_OS will not be reset to whatever native wants. even if you redefine TARGET_SYS may not be sufficient. Somehow if you can make native.bbclass to stubbornly ignore TARGET_OS override that might work. > >> >> I don't think this is the right thing; native.bbclass already assigns >> TARGET_OS = "${BUILD_OS}". >> >> Do you really need to use a _local override for TARGET_OS? If so then I >> guess you need to find a way to stop it applying for virtclass-native. >> >> p. >> >> >> >> _______________________________________________ >> Openembedded-devel mailing list >> Openembedded-devel@lists.openembedded.org >> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel >> > ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH] native.bbclass: add (re)definitions for TARGET_SYS and HOST_SYS 2010-08-20 15:44 ` Khem Raj @ 2010-08-20 16:48 ` Frans Meulenbroeks 2010-08-20 18:40 ` Tom Rini 0 siblings, 1 reply; 6+ messages in thread From: Frans Meulenbroeks @ 2010-08-20 16:48 UTC (permalink / raw) To: openembedded-devel 2010/8/20 Khem Raj <raj.khem@gmail.com>: > On Fri, Aug 20, 2010 at 8:34 AM, Khem Raj <raj.khem@gmail.com> wrote: >> On Fri, Aug 20, 2010 at 7:39 AM, Phil Blundell <philb@gnu.org> wrote: >>> On Fri, 2010-08-20 at 16:19 +0200, Frans Meulenbroeks wrote: >>>> @@ -23,6 +23,7 @@ TARGET_VENDOR = "${BUILD_VENDOR}" >>>> TARGET_PREFIX = "${BUILD_PREFIX}" >>>> TARGET_CC_ARCH = "${BUILD_CC_ARCH}" >>>> TARGET_EXEEXT = "${BUILD_EXEEXT}" >>>> +TARGET_SYS = "${BUILD_SYS}" >> >> bitbake.conf already has >> >> TARGET_SYS=${TARGET_ARCH}${TARGET_VENDOR}${@['-' + >> bb.data.getVar('TARGET_OS', d, 1), ''][bb.data.getVar('TARGET_OS', d, >> 1) == ('' or 'custom')]} >> >> so once you have TARGET_OS set correctly this should work well for native too. > > > hmm _local ok if you override TARGET_OS locally then lot of other > things will change > because now TARGET_OS will not be reset to whatever native wants. even if you > redefine TARGET_SYS may not be sufficient. Somehow if you can make > native.bbclass > to stubbornly ignore TARGET_OS override that might work. > I don't want to override TARGET_OS (and in fact this could be done in the machine definition). The hardware I am working with is a powerpc system quite similar to calamari. It is an e500v2 which supports/needs spe. For calamari/angstrom things work by the grace of the following code in angstrom.eglibc.inc: TARGET_OS = "linux" TARGET_OS .= "${@['','-gnueabi'][bb.data.getVar('TARGET_ARCH',d,1) in ['arm', 'armeb']]}" TARGET_OS .= "${@['','-gnuspe'][bb.data.getVar('TARGET_ARCH',d,1) in ['ppc', 'powerpc'] and bb.data.getVar('MACHINE',d) in ['calamari']]}" and actually if I replace calamari with my machine name it works. The code seems too specific because afaik each ppc e500 core requires gnuspe. The reason the override was there and not in the machine config, is because at some point I thought this inc file would mask my definition, so I wanted to be really really sure I got the gnuspe settings. I've had a discussion on this with pb and RP on irc, the problem is probably not here but in gmp-native. Earlier native recipes (like openssl-native, libcurses-native etc etc) build fine but for gmp-native configure fails. We've also looked at the patch for gmp-native and at least the darwin patch indicates there is something fishy here. My "patch" fixed things for me, but as it stands it is probably not the proper solution but the answer is in gmp. And my misperception was that for native recipes target and host should be the sam, but for gmp-native configure is called with --build=x86_64-linux --host=x86_64-linux --target=x86_64-linux-gnuspe and it barfs upon the target value. Is this target value ok??? As I said I expected here that build==host==target (for a native recipe). Frans PS: I'm doing a rebuild from scratch now with the patch undone and TARGET_OS being defined in the machine conf. When finished I can provide some more detailed info on the error. ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH] native.bbclass: add (re)definitions for TARGET_SYS and HOST_SYS 2010-08-20 16:48 ` Frans Meulenbroeks @ 2010-08-20 18:40 ` Tom Rini 0 siblings, 0 replies; 6+ messages in thread From: Tom Rini @ 2010-08-20 18:40 UTC (permalink / raw) To: openembedded-devel Frans Meulenbroeks wrote: > 2010/8/20 Khem Raj <raj.khem@gmail.com>: >> On Fri, Aug 20, 2010 at 8:34 AM, Khem Raj <raj.khem@gmail.com> wrote: >>> On Fri, Aug 20, 2010 at 7:39 AM, Phil Blundell <philb@gnu.org> wrote: >>>> On Fri, 2010-08-20 at 16:19 +0200, Frans Meulenbroeks wrote: >>>>> @@ -23,6 +23,7 @@ TARGET_VENDOR = "${BUILD_VENDOR}" >>>>> TARGET_PREFIX = "${BUILD_PREFIX}" >>>>> TARGET_CC_ARCH = "${BUILD_CC_ARCH}" >>>>> TARGET_EXEEXT = "${BUILD_EXEEXT}" >>>>> +TARGET_SYS = "${BUILD_SYS}" >>> bitbake.conf already has >>> >>> TARGET_SYS=${TARGET_ARCH}${TARGET_VENDOR}${@['-' + >>> bb.data.getVar('TARGET_OS', d, 1), ''][bb.data.getVar('TARGET_OS', d, >>> 1) == ('' or 'custom')]} >>> >>> so once you have TARGET_OS set correctly this should work well for native too. >> >> hmm _local ok if you override TARGET_OS locally then lot of other >> things will change >> because now TARGET_OS will not be reset to whatever native wants. even if you >> redefine TARGET_SYS may not be sufficient. Somehow if you can make >> native.bbclass >> to stubbornly ignore TARGET_OS override that might work. >> > I don't want to override TARGET_OS (and in fact this could be done in > the machine definition). > > The hardware I am working with is a powerpc system quite similar to > calamari. It is an e500v2 which supports/needs spe. > For calamari/angstrom things work by the grace of the following code > in angstrom.eglibc.inc: In essence, Angstrom needs the logic compute_os_portion_of_target_triplet() in sane-toolchain.inc has, for doing -gnuspe if it's going to support PPC more widely. -- Tom Rini Mentor Graphics Corporation ^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2010-08-20 18:40 UTC | newest] Thread overview: 6+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2010-08-20 14:19 [PATCH] native.bbclass: add (re)definitions for TARGET_SYS and HOST_SYS Frans Meulenbroeks 2010-08-20 14:39 ` Phil Blundell 2010-08-20 15:34 ` Khem Raj 2010-08-20 15:44 ` Khem Raj 2010-08-20 16:48 ` Frans Meulenbroeks 2010-08-20 18:40 ` Tom Rini
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.