x86_64

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

[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

[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

[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

[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

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