x86_64

x86_64

[Franck]

Hi,

i've a AMD Athlon(tm) 64 Processor 3000+ with 1Go RAM and HD 80Go IDE 
running SUSE 9.1 pro.

If i could help developpers for testing the new x86_64 patch, i'm here :)

Regards

Franck


-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click

Re: x86_64

[Keir Fraser]

On 27 Feb 2005, at 13:21, Franck wrote:

> i've a AMD Athlon(tm) 64 Processor 3000+ with 1Go RAM and HD 80Go IDE 
> running SUSE 9.1 pro.
>
> If i could help developpers for testing the new x86_64 patch, i'm here 
> :)

The Xen side of things is all there. The XenLinux code should also be 
available in the next week or so (being worked on by Intel -- it sounds 
like it's making good progress).

  -- Keir



-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click

Re: x86_64

[Ronald G. Minnich]

On Sun, 27 Feb 2005, Keir Fraser wrote:

> The Xen side of things is all there. The XenLinux code should also be
> available in the next week or so (being worked on by Intel -- it sounds
> like it's making good progress).

excellent timing, I'm thinking that I can use this to test the first 
64-bit plan 9 ports!

ron


-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click

RE: x86_64

[Puthiyaparambil, Aravindh]

Any idea what the memory limitations of x64 Xen will be? What is the max
memory the host and guest can handle?

-----Original Message-----
From: xen-devel-admin@lists.sourceforge.net
[mailto:xen-devel-admin@lists.sourceforge.net] On Behalf Of Ronald G.
Minnich
Sent: Sunday, February 27, 2005 10:51 PM
To: Keir Fraser
Cc: Franck; xen-devel
Subject: Re: [Xen-devel] x86_64



On Sun, 27 Feb 2005, Keir Fraser wrote:

> The Xen side of things is all there. The XenLinux code should also be
> available in the next week or so (being worked on by Intel -- it
sounds
> like it's making good progress).

excellent timing, I'm thinking that I can use this to test the first 
64-bit plan 9 ports!

ron


-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/xen-devel


-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_ide95&alloc_id\x14396&op=click

Re: x86_64

[Keir Fraser]

On 1 Mar 2005, at 16:01, Puthiyaparambil, Aravindh wrote:

> Any idea what the memory limitations of x64 Xen will be? What is the 
> max
> memory the host and guest can handle?

We'll support as much memory as the current chip architecture can 
handle -- that's up to 1TB of memory for current Opterons.

  -- Keir



-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click

RE: x86_64

[Ian Pratt]

 
> Any idea what the memory limitations of x64 Xen will be? What 
> is the max
> memory the host and guest can handle?

The current memory layout is good for 5TB of memory.

Ian


-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_ide95&alloc_id\x14396&op=click

Re: x86_64

[Matt Ayres]

*drools* ... can't wait!

----- Original Message ----- 
From: "Ian Pratt" <m+Ian.Pratt@cl.cam.ac.uk>
To: "Puthiyaparambil, Aravindh" <aravindh.puthiyaparambil@unisys.com>; 
"Ronald G. Minnich" <rminnich@lanl.gov>; "Keir Fraser" 
<Keir.Fraser@cl.cam.ac.uk>
Cc: "Franck" <franck@linuxpourtous.com>; "xen-devel" 
<xen-devel@lists.sourceforge.net>; <ian.pratt@cl.cam.ac.uk>
Sent: Tuesday, March 01, 2005 1:15 PM
Subject: RE: [Xen-devel] x86_64



> Any idea what the memory limitations of x64 Xen will be? What
> is the max
> memory the host and guest can handle?

The current memory layout is good for 5TB of memory.

Ian


-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_ide95&alloc_id\x14396&op=ick
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/xen-devel



-- 
No virus found in this outgoing message.
Checked by AVG Anti-Virus.
Version: 7.0.300 / Virus Database: 266.5.4 - Release Date: 3/1/2005



-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click

X86_64

[David_Wolinsky]

[-- Attachment #1.1: Type: text/plain, Size: 241 bytes --]

Just to make things clear, I was reading through the x86_64 take 2 and I
wasn't sure what the conclusion was... For Intel chips are we supposed
to disable the NX bit?  I too am getting those nasty dereference
messages.

Thanks,
David

[-- Attachment #1.2: Type: text/html, Size: 682 bytes --]

[-- Attachment #2: Type: text/plain, Size: 138 bytes --]

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

RE: X86_64

[Nakajima, Jun]

 
>  Just to make things clear, I was reading through the x86_64 take 2
and I wasn't sure what  
>  the conclusion was... For Intel chips are we supposed to disable the
NX bit?  I too am  
>  getting those nasty dereference messages.

No, that's opposite, i.e. NX/XD needs to be _enabled_. 

 > Thanks, 
 > David

Jun
---
Intel Open Source Technology Center 
________________________________

From: xen-devel-bounces@lists.xensource.com
[mailto:xen-devel-bounces@lists.xensource.com] On Behalf Of
David_Wolinsky@Dell.com
Sent: Thursday, July 28, 2005 7:41 AM
To: xen-devel@lists.xensource.com
Subject: [Xen-devel] X86_64



 

x86_64

[Lucas Diaz]

Is there better performance of iptables on a x86_64 enviroment than i386 
(Fedora)?
How do I compile it?
Thanks.
Lucas.

x86_64

[Jaap de Jong]

Hi All,

is there any support for 64 bit intel/amd machines?
And if so, how to build for them?

Thanks!
Jaap

Re: x86_64

[Bernhard Reutner-Fischer]

On Tue, May 10, 2011 at 10:13:22AM +0200, Jaap de Jong wrote:
>Hi All,
>
>is there any support for 64 bit intel/amd machines?
>And if so, how to build for them?

Can we settle on a name please for i want to add a qemu machine for
testing x86_64?

x8664
amd64
...

Opinions?

thanks,

Re: x86_64

[Eric Bénard]

HI,

On 10/05/2011 12:00, Bernhard Reutner-Fischer wrote:
> On Tue, May 10, 2011 at 10:13:22AM +0200, Jaap de Jong wrote:
>> Hi All,
>>
>> is there any support for 64 bit intel/amd machines?
>> And if so, how to build for them?
>
> Can we settle on a name please for i want to add a qemu machine for
> testing x86_64?
>
> x8664
> amd64
> ...
>
> Opinions?
>
amd64 like debian, gentoo & co

Eric

Re: x86_64

[Phil Blundell]

On Tue, 2011-05-10 at 12:00 +0200, Bernhard Reutner-Fischer wrote:
> On Tue, May 10, 2011 at 10:13:22AM +0200, Jaap de Jong wrote:
> >Hi All,
> >
> >is there any support for 64 bit intel/amd machines?
> >And if so, how to build for them?
> 
> Can we settle on a name please for i want to add a qemu machine for
> testing x86_64?
> 
> x8664
> amd64
> ...
> 
> Opinions?

"x86_64" seems to be what's currently used as the architecture name.  If
you want a value for ${MACHINE} then I guess something like
"x86_64-generic" would do.  I don't think there's any prohibition
against underscores in machine names.

p.

Re: x86_64

[Jaap de Jong]

On 05/10/2011 12:06 PM, Phil Blundell wrote:
> On Tue, 2011-05-10 at 12:00 +0200, Bernhard Reutner-Fischer wrote:
>> On Tue, May 10, 2011 at 10:13:22AM +0200, Jaap de Jong wrote:
>>> Hi All,
>>>
>>> is there any support for 64 bit intel/amd machines?
>>> And if so, how to build for them?
>> Can we settle on a name please for i want to add a qemu machine for
>> testing x86_64?
>>
>> x8664
>> amd64
>> ...
>>
>> Opinions?
> "x86_64" seems to be what's currently used as the architecture name.  If
> you want a value for ${MACHINE} then I guess something like
> "x86_64-generic" would do.  I don't think there's any prohibition
> against underscores in machine names.
>
> p.

So I'm guessing it is not possible at this very moment?

Jaap.

Re: x86_64

[Phil Blundell]

On Tue, 2011-05-10 at 13:02 +0200, Jaap de Jong wrote:
> 
> On 05/10/2011 12:06 PM, Phil Blundell wrote:
> > On Tue, 2011-05-10 at 12:00 +0200, Bernhard Reutner-Fischer wrote:
> >> On Tue, May 10, 2011 at 10:13:22AM +0200, Jaap de Jong wrote:
> >>> Hi All,
> >>>
> >>> is there any support for 64 bit intel/amd machines?
> >>> And if so, how to build for them?
> >> Can we settle on a name please for i want to add a qemu machine for
> >> testing x86_64?
> >>
> >> x8664
> >> amd64
> >> ...
> >>
> >> Opinions?
> > "x86_64" seems to be what's currently used as the architecture name.  If
> > you want a value for ${MACHINE} then I guess something like
> > "x86_64-generic" would do.  I don't think there's any prohibition
> > against underscores in machine names.
> >
> > p.
> 
> So I'm guessing it is not possible at this very moment?

Depends what you mean by "not possible".  There doesn't seem to be any
existing machine config file which targets x86_64, but I don't think
there is any reason that you couldn't trivially create one; something
along the lines of:

$ cat >conf/machine/x84_64-generic.conf <<EOF
TARGET_ARCH = "x86_64"
GLIBC_ADDONS = "nptl"
GLIBC_EXTRA_OECONF = "--with-tls"
PREFERRED_PROVIDER_virtual/kernel = "linux"
KERNEL_IMAGETYPE = "bzImage"
EOF
$

p.

Re: x86_64

[Jaap de Jong]

>>>>> is there any support for 64 bit intel/amd machines?
>>>>> And if so, how to build for them?
>>>> Can we settle on a name please for i want to add a qemu machine for
>>>> testing x86_64?
>>>>
>>>> x8664
>>>> amd64
>>>> ...
>>>>
>>>> Opinions?
>>> "x86_64" seems to be what's currently used as the architecture name.  If
>>> you want a value for ${MACHINE} then I guess something like
>>> "x86_64-generic" would do.  I don't think there's any prohibition
>>> against underscores in machine names.
>>>
>>> p.
>> So I'm guessing it is not possible at this very moment?
> Depends what you mean by "not possible".  There doesn't seem to be any
> existing machine config file which targets x86_64, but I don't think
> there is any reason that you couldn't trivially create one; something
> along the lines of:
>
> $ cat>conf/machine/x84_64-generic.conf<<EOF
> TARGET_ARCH = "x86_64"
> GLIBC_ADDONS = "nptl"
> GLIBC_EXTRA_OECONF = "--with-tls"
> PREFERRED_PROVIDER_virtual/kernel = "linux"
> KERNEL_IMAGETYPE = "bzImage"
> EOF
> $
>
> p.
Will try that; is there any 64 bit output to be expected?
Jaap.

Re: x86_64

[Jaap de Jong]

>>>>>> is there any support for 64 bit intel/amd machines?
>>>>>> And if so, how to build for them?
>>>>> Can we settle on a name please for i want to add a qemu machine for
>>>>> testing x86_64?
>>>>>
>>>>> x8664
>>>>> amd64
>>>>> ...
>>>>>
>>>>> Opinions?
>>>> "x86_64" seems to be what's currently used as the architecture name.  If
>>>> you want a value for ${MACHINE} then I guess something like
>>>> "x86_64-generic" would do.  I don't think there's any prohibition
>>>> against underscores in machine names.
>>>>
>>>> p.
>>> So I'm guessing it is not possible at this very moment?
>> Depends what you mean by "not possible".  There doesn't seem to be any
>> existing machine config file which targets x86_64, but I don't think
>> there is any reason that you couldn't trivially create one; something
>> along the lines of:
>>
>> $ cat>conf/machine/x84_64-generic.conf<<EOF
>> TARGET_ARCH = "x86_64"
>> GLIBC_ADDONS = "nptl"
>> GLIBC_EXTRA_OECONF = "--with-tls"
>> PREFERRED_PROVIDER_virtual/kernel = "linux"
>> KERNEL_IMAGETYPE = "bzImage"
>> EOF
>> $
>>
>> p.
> Will try that; is there any 64 bit output to be expected?
> Jaap.
>

bitbake ends with
| 
/media/OpenEmbedded/release-2010.12/tmp/sysroots/i686-linux/usr/x86_64/x86_64-angstrom-linux/bin/ld: 
cannot find /lib64/libc.so.6 inside 
/media/OpenEmbedded/release-2010.12/tmp/sysroots/x86_64-angstrom-linux

There is only a lib directory and no lib64 directory...

Jaap

Re: x86_64

[Phil Blundell]

On Tue, 2011-05-10 at 14:57 +0200, Jaap de Jong wrote:
> bitbake ends with
> | 
> /media/OpenEmbedded/release-2010.12/tmp/sysroots/i686-linux/usr/x86_64/x86_64-angstrom-linux/bin/ld: 
> cannot find /lib64/libc.so.6 inside 
> /media/OpenEmbedded/release-2010.12/tmp/sysroots/x86_64-angstrom-linux
> 
> There is only a lib directory and no lib64 directory...

It seems that there is some disagreement between binutils and your C
library about where the libs should be stored.  Which DISTRO
configuration are you using?

If you make a symlink from lib -> lib64 inside the sysroot, does that
allow the build to continue?

p.

Re: x86_64

[Jaap de Jong]

On 05/10/2011 04:38 PM, Phil Blundell wrote:
> On Tue, 2011-05-10 at 14:57 +0200, Jaap de Jong wrote:
>> bitbake ends with
>> |
>> /media/OpenEmbedded/release-2010.12/tmp/sysroots/i686-linux/usr/x86_64/x86_64-angstrom-linux/bin/ld:
>> cannot find /lib64/libc.so.6 inside
>> /media/OpenEmbedded/release-2010.12/tmp/sysroots/x86_64-angstrom-linux
>>
>> There is only a lib directory and no lib64 directory...
> It seems that there is some disagreement between binutils and your C
> library about where the libs should be stored.  Which DISTRO
> configuration are you using?
Build Configuration:
BB_VERSION        = "1.8.18"
METADATA_BRANCH   = "release-2010.12"
METADATA_REVISION = "dec3967"
TARGET_ARCH       = "x86_64"
TARGET_OS         = "linux"
MACHINE           = "x86_64-generic"
DISTRO            = "angstrom"
DISTRO_VERSION    = "2010.12"

> If you make a symlink from lib ->  lib64 inside the sysroot, does that
> allow the build to continue?
>

Tried that one...
| 
/media/OpenEmbedded/release-2010.12/tmp/sysroots/i686-linux/usr/x86_64/x86_64-angstrom-linux/bin/ld: 
cannot find /lib64/libc.so.6 inside 
/media/OpenEmbedded/release-2010.12/tmp/sysroots/x86_64-angstrom-linux

so the answer is: no...

Jaap

Re: x86_64

[Enrico Scholz]

Jaap de Jong <jaap.dejong@nedap.com> writes:

> TARGET_ARCH       = "x86_64"

did this ever work?  OE uses hardcoded 'lib' (instead of 'lib64') at
various places.  At least gcc has

| #define GLIBC_DYNAMIC_LINKER64 "/lib64/ld-linux-x86-64.so.2"

which causes 64 bit binaries to look for the interpreter at /lib64.

I recall issues with openssl too which autodetects lib64 directories but
OE packages lib only.



Enrico

Re: x86_64

[Michael Smith]

On Tue, 10 May 2011, Enrico Scholz wrote:

> Jaap de Jong <jaap.dejong@nedap.com> writes:
> 
> > TARGET_ARCH       = "x86_64"
> 
> did this ever work?  OE uses hardcoded 'lib' (instead of 'lib64') at
> various places.

Hi Enrico,

This is my MACHINE config:

TARGET_ARCH = "x86_64"

# We can't reuse the same -native builds as 32-bit machines, because
# ours need to be staged into staging/blah/lib64 instead of lib.
# Set blah to x86_64-buildoe64-linux to keep them separate.
BUILD_VENDOR = "-buildoe64"

base_libdir = "${base_prefix}/lib64"
libdir = "${exec_prefix}/lib64"

# Some packages install files into /lib/packagename, not /lib64/packagename.
FILES_${PN} += "${prefix}/lib/${PN}/*"
FILES_${PN}-dbg += "${prefix}/lib/${PN}/.debug"

# glibc's sysdeps/unix/sysv/linux/configure script only fixes
# libc_cv_slibdir if prefix is "/usr". With prefix of "", we need to fix it
# so libc libs don't get installed into /lib.
export libc_cv_slibdir="/lib64"

--------

I had to amend gcc-cross-intermediate:

do_compile_prepend() {
	# On x86_64, glibc-initial stages crti.o to
	# x86_64-oe-linux/lib64/crti.o.
	# When gcc-cross-intermediate tries to build libgcc, it looks
	# for x86_64-oe-linux/lib/../lib64/crti.o.
	# Create the "lib" dir so this shenanigan works.
	install -d ${STAGING_DIR_TARGET}/lib
}


And gcc-cross:

# glibc only built the 64-bit stubs, so don't try to build a 32-bit gcc
# XXX maybe belongs in oe recipes/gcc/gcc-cross4.inc
EXTRA_OECONF_append_x86_64 = " --disable-multilib"


I think that's it - for the recipes I build, all the other fixes have been 
pushed long ago.

Mike

Re: x86_64

[Enrico Scholz]

Michael Smith <msmith@cbnco.com> writes:

>> did this ever work?  OE uses hardcoded 'lib' (instead of 'lib64') at
>> various places.
>
> This is my MACHINE config:
> ...
> # Some packages install files into /lib/packagename, not /lib64/packagename.
> FILES_${PN} += "${prefix}/lib/${PN}/*"
> FILES_${PN}-dbg += "${prefix}/lib/${PN}/.debug"

I think, this will break/change some packages...


After creating (manually) lib64 -> lib symlinks in the sysroot, I managed
to build a non trivial 64-bit system (e.g. with vdr and perl stuff) with
(nearly) standard settings (2011.03-maintenance).  But necessary tricks
like the BUILD_VENDOR and some minor fixes (like these in openssl) caused
me to see this as very experimental.


> And gcc-cross:
> EXTRA_OECONF_append_x86_64 = " --disable-multilib"

should not be needed anymore; flag is set by
847c0dadb9f55af5cc4556486cde3d9dcc2129af


Enrico

Re: x86_64

[Bernhard Reutner-Fischer]

On Tue, May 10, 2011 at 11:06:44AM +0100, Phil Blundell wrote:
>On Tue, 2011-05-10 at 12:00 +0200, Bernhard Reutner-Fischer wrote:
>> On Tue, May 10, 2011 at 10:13:22AM +0200, Jaap de Jong wrote:
>> >Hi All,
>> >
>> >is there any support for 64 bit intel/amd machines?
>> >And if so, how to build for them?
>> 
>> Can we settle on a name please for i want to add a qemu machine for
>> testing x86_64?
>> 
>> x8664
>> amd64
>> ...
>> 
>> Opinions?
>
>"x86_64" seems to be what's currently used as the architecture name.  If

That doesn't work as arch-dependent e.g. append, does it.

FOO_append_x86_64 = '-mcpu=barcelona'

>you want a value for ${MACHINE} then I guess something like
>"x86_64-generic" would do.  I don't think there's any prohibition
>against underscores in machine names.

Well, I was talking about the arch.

Re: x86_64

[Michael Smith]

------- Original message -------
> From: Bernhard Reutner-Fischer <rep.dot.nop@gmail.com>
> On Tue, May 10, 2011 at 11:06:44AM +0100, Phil Blundell wrote:
>>
>>"x86_64" seems to be what's currently used as the architecture name.  If
>
> That doesn't work as arch-dependent e.g. append, does it.
>
> FOO_append_x86_64 = '-mcpu=barcelona'

I believe it does work.

Mike 

Re: x86_64

[Phil Blundell]

On Tue, 2011-05-10 at 18:15 +0200, Bernhard Reutner-Fischer wrote:
> On Tue, May 10, 2011 at 11:06:44AM +0100, Phil Blundell wrote:
> >"x86_64" seems to be what's currently used as the architecture name.  If
> 
> That doesn't work as arch-dependent e.g. append, does it.
> 
> FOO_append_x86_64 = '-mcpu=barcelona'

It seems to work just fine for me.  What goes wrong for you?

$ cat >t.bb <<EOF
TARGET_ARCH = "x86_64"
x = "a"
x_append_x86_64 = "b"
x_append_x87_65 = "c"
EOF
$ bitbake -e -b t.bb |grep ^x
x="ab"
$

p.

Re: x86_64

[Bernhard Reutner-Fischer]

On Tue, May 10, 2011 at 06:51:47PM +0100, Phil Blundell wrote:
>On Tue, 2011-05-10 at 18:15 +0200, Bernhard Reutner-Fischer wrote:
>> On Tue, May 10, 2011 at 11:06:44AM +0100, Phil Blundell wrote:
>> >"x86_64" seems to be what's currently used as the architecture name.  If
>> 
>> That doesn't work as arch-dependent e.g. append, does it.
>> 
>> FOO_append_x86_64 = '-mcpu=barcelona'
>
>It seems to work just fine for me.  What goes wrong for you?

It was OVERRIDES as Enrico mentioned.
Given that both khem in (IIRC) 2009 and me a year later stumbled across
the name and abandoned the thing in consequence, settling on an example
name would be nice -- nowadays i would just use amd64 but that won't
happen anytime soon, unfortunately.
Both patches should be in the old patchwork, for reference.

cheers,

Re: x86_64

[Enrico Scholz]

Phil Blundell <philb@gnu.org> writes:

> "x86_64" seems to be what's currently used as the architecture name.  If
> you want a value for ${MACHINE} then I guess something like
> "x86_64-generic" would do.  I don't think there's any prohibition
> against underscores in machine names.

OVERRIDES don't work correctly with this. E.g. (bitbake 1.10) a recipe
with

| xx = "default"
| xx_x86_64 = "XX"

results into

| OVERRIDES="...:x86_64:..."
| # xx_x86_64=XX
| xx_x86_64="XX"
| # xx=default
| xx="default"


Adding an additional "x86-64" to OVERRIDES in the machine configuration
and using it by

| xx_x86-64 = "XX"

gives the expected

| # xx_x86-64=XX
| xx_x86-64="XX"
| # xx=XX
| xx="XX"



Enrico

Re: x86_64

[Phil Blundell]

On Tue, 2011-05-10 at 18:38 +0200, Enrico Scholz wrote:
> Phil Blundell <philb@gnu.org> writes:
> 
> > "x86_64" seems to be what's currently used as the architecture name.  If
> > you want a value for ${MACHINE} then I guess something like
> > "x86_64-generic" would do.  I don't think there's any prohibition
> > against underscores in machine names.
> 
> OVERRIDES don't work correctly with this. E.g. (bitbake 1.10) a recipe
> with
> 
> | xx = "default"
> | xx_x86_64 = "XX"
> 
> results into
> 
> | OVERRIDES="...:x86_64:..."
> | # xx_x86_64=XX
> | xx_x86_64="XX"
> | # xx=default
> | xx="default"

Yes, you're right.  But it seems as though _append overrides do work
(see my other mail to Bernhard Reutner-Fischer), and I don't think the
bitbake documentation notes that underscores are prohibited in
OVERRIDES.  So I think this is a bug in bitbake and should be fixed
there.

Changing the architecture to x86-64 would be a possibility, but clearly
there are already folks using x86_64 (since there are files in site/
with that naming, for example) so this seems like it would be best
avoided.  Also it would require a tmpdir version bump to take care of
BUILD_SYS for all the people who are cross compiling from x86_64, and
that also seems like something best avoided if possible.

p.

Re: x86_64

[Enrico Scholz]

Phil Blundell <philb@gnu.org> writes:

> Changing the architecture to x86-64 would be a possibility, 

no; will cause too much pain because all the ./config.guess scripts
expect 'x86_64'.

I kept TARGET_ARCH='x86_64' but added an additional OVERRIDES where '_'
is replaced by '-'.


Enrico

Re: x86_64

[Khem Raj]

On (10/05/11 10:13), Jaap de Jong wrote:
> Hi All,
> 
> is there any support for 64 bit intel/amd machines?
> And if so, how to build for them?

classic oe does not have it but there are patches posted look through
mailing list archives

fwiw. oe-core has a working support for x86_64 architecture it will be
worthwhile looking at that

-Khem

Re: x86_64

[Phil Blundell]

On Sun, 2011-05-15 at 15:11 -0700, Khem Raj wrote:
> fwiw. oe-core has a working support for x86_64 architecture it will be
> worthwhile looking at that

How did oe-core solve the problem with OVERRIDES?

p.