| Submitter | Khem Raj |
|---|---|
| Date | 2009-12-17 20:07:33 |
| Message ID | <1261080453-12752-1-git-send-email-raj.khem@gmail.com> |
| Download | mbox | patch |
| Permalink | /patch/1402/ |
| State | Deferred |
| Headers | show |
Comments
On Thu, 2009-12-17 at 12:07 -0800, Khem Raj wrote: > * This is not supporting multilib > * Only 64-bit userspace can be built. > > --- /dev/null > +++ b/conf/machine/include/tune-x86_64.inc > @@ -0,0 +1,4 @@ > +TARGET_CC_ARCH = "-mtune=generic" > +BASE_PACKAGE_ARCH = "x86_64" > +FEED_ARCH = "x86_64" > +PACKAGE_EXTRA_ARCHS += "x86 i386 i486 i586 i686" If this is a pure 64-bit environment, surely you don't want that stuff in PACKAGE_EXTRA_ARCHS. It's also not completely obvious to me that this stuff belongs in a tune-* file at all, or indeed that it makes much sense to talk about "tuning" for generic x86-64 in the first place. p.
On Thu, Dec 17, 2009 at 12:22 PM, Phil Blundell <philb@gnu.org> wrote: > On Thu, 2009-12-17 at 12:07 -0800, Khem Raj wrote: >> * This is not supporting multilib >> * Only 64-bit userspace can be built. >> >> --- /dev/null >> +++ b/conf/machine/include/tune-x86_64.inc >> @@ -0,0 +1,4 @@ >> +TARGET_CC_ARCH = "-mtune=generic" >> +BASE_PACKAGE_ARCH = "x86_64" >> +FEED_ARCH = "x86_64" >> +PACKAGE_EXTRA_ARCHS += "x86 i386 i486 i586 i686" > > If this is a pure 64-bit environment, surely you don't want that stuff > in PACKAGE_EXTRA_ARCHS. right I will remove it. > > It's also not completely obvious to me that this stuff belongs in a > tune-* file at all, or indeed that it makes much sense to talk about > "tuning" for generic x86-64 in the first place. most of tune files have PACKAGE_EXTRA_ARCHS so it could be another cleaning which needs in tune files. as the machine is for x86_64 generic I think tuning for generic is a good match infact chosing mcpu=generic should be done too. > > p. > > > > _______________________________________________ > Openembedded-devel mailing list > Openembedded-devel@lists.openembedded.org > http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel >
On 12/17/2009 03:07 PM, Khem Raj wrote: > * This is not supporting multilib > * Only 64-bit userspace can be built. > > Signed-off-by: Khem Raj<raj.khem@gmail.com> > --- > conf/machine/include/tune-x86_64.inc | 4 ++++ > conf/machine/x86_64-generic.conf | 31 +++++++++++++++++++++++++++++++ > recipes/gcc/gcc-common.inc | 4 ++++ > 3 files changed, 39 insertions(+), 0 deletions(-) > create mode 100644 conf/machine/include/tune-x86_64.inc > create mode 100644 conf/machine/x86_64-generic.conf > > diff --git a/conf/machine/include/tune-x86_64.inc b/conf/machine/include/tune-x86_64.inc > new file mode 100644 > index 0000000..db2a560 > --- /dev/null > +++ b/conf/machine/include/tune-x86_64.inc > @@ -0,0 +1,4 @@ > +TARGET_CC_ARCH = "-mtune=generic" > +BASE_PACKAGE_ARCH = "x86_64" > +FEED_ARCH = "x86_64" > +PACKAGE_EXTRA_ARCHS += "x86 i386 i486 i586 i686" > diff --git a/conf/machine/x86_64-generic.conf b/conf/machine/x86_64-generic.conf > new file mode 100644 > index 0000000..0dad0ff > --- /dev/null > +++ b/conf/machine/x86_64-generic.conf Any chance bitbake will find the underscore confusing in the machine name? Philip > @@ -0,0 +1,31 @@ > +# Copyright (C) 2007,2009 Stelios Koroneos - Digital OPSiS, All Rights Reserved > +# Released under the MIT license (see packages/COPYING) > +#@TYPE: Machine > +#@NAME: x86_64-generic > +#@DESCRIPTION: Machine configuration for a generic x86_64 machine > + > + > +TARGET_ARCH = "x86_64" > + > +PREFERRED_PROVIDER_virtual/kernel = "linux" > +PREFERRED_PROVIDER_virtual/xserver = "xserver-kdrive" > +XSERVER="xserver-kdrive-vesa" > + > +KERNEL_IMAGETYPE = "bzImage" > + > +GLIBC_ADDONS = "nptl" > +GLIBC_EXTRA_OECONF = "--with-tls" > + > +IMAGE_FSTYPES ?= "ext2.gz" > +IMAGE_DEVICE_TABLES = " \ > + files/device_table-minimal.txt \ > + files/device_table_add-loop.txt \ > + files/device_table_add-scsi.txt \ > +" > + > +MACHINE_FEATURES = "kernel26 screen keyboard pci usbhost acpi ext2 x86" > +MACHINE_EXTRA_RRECOMMENDS = " kernel-modules" > + > +#tune for x86_64 > +require conf/machine/include/tune-x86_64.inc > + > diff --git a/recipes/gcc/gcc-common.inc b/recipes/gcc/gcc-common.inc > index 6e777e6..772e7a7 100644 > --- a/recipes/gcc/gcc-common.inc > +++ b/recipes/gcc/gcc-common.inc > @@ -15,6 +15,10 @@ def get_gcc_fpu_setting(bb, d): > return "--with-float=soft" > return "" > > +EXTRA_OECONF_append_x86_64 = " --disable-multilib" > +EXTRA_OECONF_append_mips64 = " --disable-multilib" > +EXTRA_OECONF_append_powerpc64 = " --disable-multilib" > + > # We really need HOST_SYS here for some packages and TARGET_SYS for others. > # For now, libgcc is most important so we fix for that - RP. > SHLIBSDIR = "${STAGING_DIR_TARGET}/shlibs"
On Thu, Dec 17, 2009 at 1:11 PM, Philip Balister <philip@balister.org> wrote: > On 12/17/2009 03:07 PM, Khem Raj wrote: >> >> * This is not supporting multilib >> * Only 64-bit userspace can be built. >> >> Signed-off-by: Khem Raj<raj.khem@gmail.com> >> --- >> conf/machine/include/tune-x86_64.inc | 4 ++++ >> conf/machine/x86_64-generic.conf | 31 >> +++++++++++++++++++++++++++++++ >> recipes/gcc/gcc-common.inc | 4 ++++ >> 3 files changed, 39 insertions(+), 0 deletions(-) >> create mode 100644 conf/machine/include/tune-x86_64.inc >> create mode 100644 conf/machine/x86_64-generic.conf >> >> diff --git a/conf/machine/include/tune-x86_64.inc >> b/conf/machine/include/tune-x86_64.inc >> new file mode 100644 >> index 0000000..db2a560 >> --- /dev/null >> +++ b/conf/machine/include/tune-x86_64.inc >> @@ -0,0 +1,4 @@ >> +TARGET_CC_ARCH = "-mtune=generic" >> +BASE_PACKAGE_ARCH = "x86_64" >> +FEED_ARCH = "x86_64" >> +PACKAGE_EXTRA_ARCHS += "x86 i386 i486 i586 i686" >> diff --git a/conf/machine/x86_64-generic.conf >> b/conf/machine/x86_64-generic.conf >> new file mode 100644 >> index 0000000..0dad0ff >> --- /dev/null >> +++ b/conf/machine/x86_64-generic.conf > > > Any chance bitbake will find the underscore confusing in the machine name? if there was an override for 64 which does not exist as of now > > Philip > > >> @@ -0,0 +1,31 @@ >> +# Copyright (C) 2007,2009 Stelios Koroneos - Digital OPSiS, All Rights >> Reserved >> +# Released under the MIT license (see packages/COPYING) >> +#@TYPE: Machine >> +#@NAME: x86_64-generic >> +#@DESCRIPTION: Machine configuration for a generic x86_64 machine >> + >> + >> +TARGET_ARCH = "x86_64" >> + >> +PREFERRED_PROVIDER_virtual/kernel = "linux" >> +PREFERRED_PROVIDER_virtual/xserver = "xserver-kdrive" >> +XSERVER="xserver-kdrive-vesa" >> + >> +KERNEL_IMAGETYPE = "bzImage" >> + >> +GLIBC_ADDONS = "nptl" >> +GLIBC_EXTRA_OECONF = "--with-tls" >> + >> +IMAGE_FSTYPES ?= "ext2.gz" >> +IMAGE_DEVICE_TABLES = " \ >> + files/device_table-minimal.txt \ >> + files/device_table_add-loop.txt \ >> + files/device_table_add-scsi.txt \ >> +" >> + >> +MACHINE_FEATURES = "kernel26 screen keyboard pci usbhost acpi ext2 x86" >> +MACHINE_EXTRA_RRECOMMENDS = " kernel-modules" >> + >> +#tune for x86_64 >> +require conf/machine/include/tune-x86_64.inc >> + >> diff --git a/recipes/gcc/gcc-common.inc b/recipes/gcc/gcc-common.inc >> index 6e777e6..772e7a7 100644 >> --- a/recipes/gcc/gcc-common.inc >> +++ b/recipes/gcc/gcc-common.inc >> @@ -15,6 +15,10 @@ def get_gcc_fpu_setting(bb, d): >> return "--with-float=soft" >> return "" >> >> +EXTRA_OECONF_append_x86_64 = " --disable-multilib" >> +EXTRA_OECONF_append_mips64 = " --disable-multilib" >> +EXTRA_OECONF_append_powerpc64 = " --disable-multilib" >> + >> # We really need HOST_SYS here for some packages and TARGET_SYS for >> others. >> # For now, libgcc is most important so we fix for that - RP. >> SHLIBSDIR = "${STAGING_DIR_TARGET}/shlibs" > > _______________________________________________ > Openembedded-devel mailing list > Openembedded-devel@lists.openembedded.org > http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel >
Dnia czwartek, 17 grudnia 2009 o 21:22:58 Phil Blundell napisał(a): > On Thu, 2009-12-17 at 12:07 -0800, Khem Raj wrote: > > * This is not supporting multilib > > * Only 64-bit userspace can be built. > > > > --- /dev/null > > +++ b/conf/machine/include/tune-x86_64.inc > > @@ -0,0 +1,4 @@ > > +TARGET_CC_ARCH = "-mtune=generic" > > +BASE_PACKAGE_ARCH = "x86_64" > > +FEED_ARCH = "x86_64" > > +PACKAGE_EXTRA_ARCHS += "x86 i386 i486 i586 i686" > > If this is a pure 64-bit environment, surely you don't want that stuff > in PACKAGE_EXTRA_ARCHS. > > It's also not completely obvious to me that this stuff belongs in a > tune-* file at all We moved PACKAGE_EXTRA_ARCHS from machine configs to tune-* files to cleanup situation where some machines lacked working archs or had them just wrong. Regards,
Am Donnerstag, den 17.12.2009, 12:07 -0800 schrieb Khem Raj: > * This is not supporting multilib > * Only 64-bit userspace can be built. > > Signed-off-by: Khem Raj <raj.khem@gmail.com> > --- > conf/machine/include/tune-x86_64.inc | 4 ++++ > conf/machine/x86_64-generic.conf | 31 +++++++++++++++++++++++++++++++ > recipes/gcc/gcc-common.inc | 4 ++++ > 3 files changed, 39 insertions(+), 0 deletions(-) > create mode 100644 conf/machine/include/tune-x86_64.inc > create mode 100644 conf/machine/x86_64-generic.conf I do not know how OE handles it, but is there a list of available machines where this new machine has to be added? That means keep documentation up to date. I guess I can add this new machine to local.conf (MACHINE = "x86_64-generic")? […] > diff --git a/conf/machine/x86_64-generic.conf b/conf/machine/x86_64-generic.conf > new file mode 100644 > index 0000000..0dad0ff > --- /dev/null > +++ b/conf/machine/x86_64-generic.conf > @@ -0,0 +1,31 @@ > +# Copyright (C) 2007,2009 Stelios Koroneos - Digital OPSiS, All Rights Reserved Since this is a new file, is this copyright correct? […] Thanks and sorry if my question are nonsense, Paul
> On Thu, 2009-12-17 at 12:07 -0800, Khem Raj wrote: >> * This is not supporting multilib >> * Only 64-bit userspace can be built. >> >> --- /dev/null >> +++ b/conf/machine/include/tune-x86_64.inc >> @@ -0,0 +1,4 @@ >> +TARGET_CC_ARCH = "-mtune=generic" >> +BASE_PACKAGE_ARCH = "x86_64" >> +FEED_ARCH = "x86_64" >> +PACKAGE_EXTRA_ARCHS += "x86 i386 i486 i586 i686" NAK! Don't use underscores in machine names since it's what bitbake is using to mark overrides. I fell into that trap twice already :( Also, please explain to me what you plan to do with 'FEED_ARCH'. regards, Koen
On Sun, Dec 20, 2009 at 11:04 AM, Koen Kooi <k.kooi@student.utwente.nl> wrote: >> On Thu, 2009-12-17 at 12:07 -0800, Khem Raj wrote: >>> >>> * This is not supporting multilib >>> * Only 64-bit userspace can be built. >>> >>> --- /dev/null >>> +++ b/conf/machine/include/tune-x86_64.inc >>> @@ -0,0 +1,4 @@ >>> +TARGET_CC_ARCH = "-mtune=generic" >>> +BASE_PACKAGE_ARCH = "x86_64" >>> +FEED_ARCH = "x86_64" >>> +PACKAGE_EXTRA_ARCHS += "x86 i386 i486 i586 i686" > > NAK! Don't use underscores in machine names since it's what bitbake is using > to mark overrides. I fell into that trap twice already :( > > Also, please explain to me what you plan to do with 'FEED_ARCH'. I was thinking of using amd64 but ARCH has to be x86_64 at least for gcc so I think we can not avoid it. may be we should make bitbake ignore certain overrides like x86_64 if thats possible at all. > > regards, > > Koen > > > _______________________________________________ > Openembedded-devel mailing list > Openembedded-devel@lists.openembedded.org > http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel >
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 21-12-09 03:13, Khem Raj wrote: > On Sun, Dec 20, 2009 at 11:04 AM, Koen Kooi <k.kooi@student.utwente.nl> wrote: >>> On Thu, 2009-12-17 at 12:07 -0800, Khem Raj wrote: >>>> >>>> * This is not supporting multilib >>>> * Only 64-bit userspace can be built. >>>> >>>> --- /dev/null >>>> +++ b/conf/machine/include/tune-x86_64.inc >>>> @@ -0,0 +1,4 @@ >>>> +TARGET_CC_ARCH = "-mtune=generic" >>>> +BASE_PACKAGE_ARCH = "x86_64" >>>> +FEED_ARCH = "x86_64" >>>> +PACKAGE_EXTRA_ARCHS += "x86 i386 i486 i586 i686" >> >> NAK! Don't use underscores in machine names since it's what bitbake is using >> to mark overrides. I fell into that trap twice already :( >> >> Also, please explain to me what you plan to do with 'FEED_ARCH'. > > I was thinking of using amd64 but ARCH has to be > x86_64 at least for gcc so I think we can not avoid > it. may be we should make bitbake ignore certain > overrides like x86_64 if thats possible at all. We re-write arch already for kernel recipes, so why can't we do the same for gcc? regards, Koen -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (Darwin) iD8DBQFLLzqAMkyGM64RGpERAtuHAJ9YxU54qCR7lAiUbjkxRqBi7ISycACeOkMG yrR9wiUNLhHC4im/yz7j92s= =Lk4J -----END PGP SIGNATURE-----
On Mon, Dec 21, 2009 at 1:06 AM, Koen Kooi <k.kooi@student.utwente.nl> wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On 21-12-09 03:13, Khem Raj wrote: >> On Sun, Dec 20, 2009 at 11:04 AM, Koen Kooi <k.kooi@student.utwente.nl> wrote: >>>> On Thu, 2009-12-17 at 12:07 -0800, Khem Raj wrote: >>>>> >>>>> * This is not supporting multilib >>>>> * Only 64-bit userspace can be built. >>>>> >>>>> --- /dev/null >>>>> +++ b/conf/machine/include/tune-x86_64.inc >>>>> @@ -0,0 +1,4 @@ >>>>> +TARGET_CC_ARCH = "-mtune=generic" >>>>> +BASE_PACKAGE_ARCH = "x86_64" >>>>> +FEED_ARCH = "x86_64" >>>>> +PACKAGE_EXTRA_ARCHS += "x86 i386 i486 i586 i686" >>> >>> NAK! Don't use underscores in machine names since it's what bitbake is using >>> to mark overrides. I fell into that trap twice already :( >>> >>> Also, please explain to me what you plan to do with 'FEED_ARCH'. >> >> I was thinking of using amd64 but ARCH has to be >> x86_64 at least for gcc so I think we can not avoid >> it. may be we should make bitbake ignore certain >> overrides like x86_64 if thats possible at all. > > We re-write arch already for kernel recipes, so why can't we do the same > for gcc? Good point. If gcc was the only one then yes it was relatively ok. But here we are talking about gcc and some other packages which have x86_64 for target architecture in their configure scripts. I thought of writing a class for target arch mapping but the recipes which depend upon TARGET_ARCH in some way will need to be taken care of. If this approach sounds reasonable I can try a bit more on amd64 Thanks -Khem > > regards, > > Koen > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.5 (Darwin) > > iD8DBQFLLzqAMkyGM64RGpERAtuHAJ9YxU54qCR7lAiUbjkxRqBi7ISycACeOkMG > yrR9wiUNLhHC4im/yz7j92s= > =Lk4J > -----END PGP SIGNATURE----- > > > _______________________________________________ > Openembedded-devel mailing list > Openembedded-devel@lists.openembedded.org > http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel >
On Sun, 2009-12-20 at 18:13 -0800, Khem Raj wrote: > I was thinking of using amd64 but ARCH has to be > x86_64 at least for gcc so I think we can not avoid > it. may be we should make bitbake ignore certain > overrides like x86_64 if thats possible at all. I guess the primary variable that gcc actually cares about is ${TARGET_SYS} (which isn't, itself, an OVERRIDE). It isn't strictly necessary for the first part of ${TARGET_SYS} to match ${TARGET_ARCH}: you could, in theory, set TARGET_SYS to "x86_64-unknown-linux-gnu" while having TARGET_ARCH = "x86-64" or some other, non-underscore-containing, value. All that said, I'm not sure that TARGET_ARCH=x86_64 will be much of an issue in practice. The only situation where I can immediately think that it would be problematic would be if both "x86" and "64" were individually to appear in OVERRIDES for some other reason, and this doesn't sound especially likely. There are already plenty of situations where you can, at least in theory, run into namespace collisions and it isn't obvious to me that the x86_64 one is especially egregious. p.
Patch
diff --git a/conf/machine/include/tune-x86_64.inc b/conf/machine/include/tune-x86_64.inc new file mode 100644 index 0000000..db2a560 --- /dev/null +++ b/conf/machine/include/tune-x86_64.inc @@ -0,0 +1,4 @@ +TARGET_CC_ARCH = "-mtune=generic" +BASE_PACKAGE_ARCH = "x86_64" +FEED_ARCH = "x86_64" +PACKAGE_EXTRA_ARCHS += "x86 i386 i486 i586 i686" diff --git a/conf/machine/x86_64-generic.conf b/conf/machine/x86_64-generic.conf new file mode 100644 index 0000000..0dad0ff --- /dev/null +++ b/conf/machine/x86_64-generic.conf @@ -0,0 +1,31 @@ +# Copyright (C) 2007,2009 Stelios Koroneos - Digital OPSiS, All Rights Reserved +# Released under the MIT license (see packages/COPYING) +#@TYPE: Machine +#@NAME: x86_64-generic +#@DESCRIPTION: Machine configuration for a generic x86_64 machine + + +TARGET_ARCH = "x86_64" + +PREFERRED_PROVIDER_virtual/kernel = "linux" +PREFERRED_PROVIDER_virtual/xserver = "xserver-kdrive" +XSERVER="xserver-kdrive-vesa" + +KERNEL_IMAGETYPE = "bzImage" + +GLIBC_ADDONS = "nptl" +GLIBC_EXTRA_OECONF = "--with-tls" + +IMAGE_FSTYPES ?= "ext2.gz" +IMAGE_DEVICE_TABLES = " \ + files/device_table-minimal.txt \ + files/device_table_add-loop.txt \ + files/device_table_add-scsi.txt \ +" + +MACHINE_FEATURES = "kernel26 screen keyboard pci usbhost acpi ext2 x86" +MACHINE_EXTRA_RRECOMMENDS = " kernel-modules" + +#tune for x86_64 +require conf/machine/include/tune-x86_64.inc + diff --git a/recipes/gcc/gcc-common.inc b/recipes/gcc/gcc-common.inc index 6e777e6..772e7a7 100644 --- a/recipes/gcc/gcc-common.inc +++ b/recipes/gcc/gcc-common.inc @@ -15,6 +15,10 @@ def get_gcc_fpu_setting(bb, d): return "--with-float=soft" return "" +EXTRA_OECONF_append_x86_64 = " --disable-multilib" +EXTRA_OECONF_append_mips64 = " --disable-multilib" +EXTRA_OECONF_append_powerpc64 = " --disable-multilib" + # We really need HOST_SYS here for some packages and TARGET_SYS for others. # For now, libgcc is most important so we fix for that - RP. SHLIBSDIR = "${STAGING_DIR_TARGET}/shlibs"
* This is not supporting multilib * Only 64-bit userspace can be built. Signed-off-by: Khem Raj <raj.khem@gmail.com> --- conf/machine/include/tune-x86_64.inc | 4 ++++ conf/machine/x86_64-generic.conf | 31 +++++++++++++++++++++++++++++++ recipes/gcc/gcc-common.inc | 4 ++++ 3 files changed, 39 insertions(+), 0 deletions(-) create mode 100644 conf/machine/include/tune-x86_64.inc create mode 100644 conf/machine/x86_64-generic.conf