[PATCH] conf/machine: Add x86_64 machine.

[PATCH] conf/machine: Add x86_64 machine.

[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

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"
-- 
1.5.4.3

Re: [PATCH] conf/machine: Add x86_64 machine.

[Phil Blundell]

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.

Re: [PATCH] conf/machine: Add x86_64 machine.

[Khem Raj]

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
>

Re: [PATCH] conf/machine: Add x86_64 machine.

[Philip Balister]

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"

Re: [PATCH] conf/machine: Add x86_64 machine.

[Khem Raj]

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
>

Re: [PATCH] conf/machine: Add x86_64 machine.

[Marcin Juszkiewicz]

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, 
-- 
JID:      hrw@jabber.org
Website:  http://marcin.juszkiewicz.com.pl/
LinkedIn: http://www.linkedin.com/in/marcinjuszkiewicz

Re: [PATCH] conf/machine: Add x86_64 machine.

[Paul Menzel]

[-- Attachment #1: Type: text/plain, Size: 1229 bytes --]

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

[-- Attachment #2: Dies ist ein digital signierter Nachrichtenteil --]
[-- Type: application/pgp-signature, Size: 205 bytes --]

Re: [PATCH] conf/machine: Add x86_64 machine.

[Koen Kooi]

> 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

Re: [PATCH] conf/machine: Add x86_64 machine.

[Khem Raj]

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
>

Re: [PATCH] conf/machine: Add x86_64 machine.

[Koen Kooi]

-----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-----

Re: [PATCH] conf/machine: Add x86_64 machine.

[Khem Raj]

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
>

Re: [PATCH] conf/machine: Add x86_64 machine.

[Phil Blundell]

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.