On Tuesday 06 December 2011 17:39:48 Mike Frysinger wrote:
> i'll post binaries here:
> http://dev.gentoo.org/~vapier/x32/
i've posted a stage3 tarball there now built with catalyst. if people want to
give it a spin and file bugs, that'd probably be cool.
notes:
- don't waste time on sta
On Thursday 08 December 2011 16:40:58 Markos Chandras wrote:
> On 12/08/2011 09:34 PM, Mike Frysinger wrote:
> > On Thursday 08 December 2011 16:29:15 Markos Chandras wrote:
> >> On 12/08/2011 09:22 PM, Mike Frysinger wrote:
> >>> the releases will include all 3 ABIs (which only affects
> >>> gcc/g
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
On 12/08/2011 09:34 PM, Mike Frysinger wrote:
> On Thursday 08 December 2011 16:29:15 Markos Chandras wrote:
>> On 12/08/2011 09:22 PM, Mike Frysinger wrote:
>>> the releases will include all 3 ABIs (which only affects
>>> gcc/glibc in terms of overh
On Thursday 08 December 2011 16:29:15 Markos Chandras wrote:
> On 12/08/2011 09:22 PM, Mike Frysinger wrote:
> > the releases will include all 3 ABIs (which only affects gcc/glibc
> > in terms of overhead). if people want to use x32 with less other
> > ABIs, then i think the expected use case will
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
On 12/08/2011 09:22 PM, Mike Frysinger wrote:
> On Thursday 15 September 2011 15:34:06 Mike Frysinger wrote:
>> ive converted my system over to x86/amd64/x32 multilib for funs.
>> but i can see how some people wont want all three all the time.
>> so
On Thursday 15 September 2011 15:34:06 Mike Frysinger wrote:
> ive converted my system over to x86/amd64/x32 multilib for funs. but i can
> see how some people wont want all three all the time. so the question is
> how we want to make this available to users at the release/profile level.
for pro
On Tuesday 06 December 2011 17:13:35 Markos Chandras wrote:
> On 12/02/2011 08:54 PM, Mike Frysinger wrote:
> > progress update: - binutils-2.22 in ~arch should work fine -
> > glibc-2.14.1-r1 in ~arch includes support when "x32" is in
> > MULTILIB_ABIS - linux-headers-3.1 includes support when "x3
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
On 12/02/2011 08:54 PM, Mike Frysinger wrote:
> progress update: - binutils-2.22 in ~arch should work fine -
> glibc-2.14.1-r1 in ~arch includes support when "x32" is in
> MULTILIB_ABIS - linux-headers-3.1 includes support when "x32" is in
> MULTILIB
On Friday 02 December 2011 15:54:09 Mike Frysinger wrote:
> - you'll still need gcc-4.7 from the toolchain overlay
i guess hjlu did a gcc-4.6 backport, so i've included that patch in 4.6.2
next step:
- build a stage3 where x32 is the default ABI
-mike
signature.asc
Description: This is a digi
On Friday 02 December 2011 16:25:15 Samuli Suominen wrote:
> On 12/02/2011 10:54 PM, Mike Frysinger wrote:
> > progress update:
> > - linux-headers-3.1 includes support when "x32" is in MULTILIB_ABIS
>
> so 3.1 will hit portage soon?
as soon as the bugs in the eclass keeping the ebuild out of t
On 12/02/2011 10:54 PM, Mike Frysinger wrote:
progress update:
- linux-headers-3.1 includes support when "x32" is in MULTILIB_ABIS
so 3.1 will hit portage soon?
progress update:
- binutils-2.22 in ~arch should work fine
- glibc-2.14.1-r1 in ~arch includes support when "x32" is in MULTILIB_ABIS
- linux-headers-3.1 includes support when "x32" is in MULTILIB_ABIS
- you'll still need gcc-4.7 from the toolchain overlay
- a 3.1 kernel can be obtained here:
On 09/16/2011 09:36, Donnie Berkholz wrote:
>
> For anyone interested how the performance compares to amd64 in more
> comprehensive tests, check out the slides from the Linux Plumbers
> Conference (particularly 14-21):
>
> http://linuxplumbersconf.org/2011/ocw/proposals/531
>
> In summary, on
On 09/15/2011 16:33, Mike Frysinger wrote:
>
> the sizeof(long) and sizeof(void*) are the same between x86 and x32.
> however,
> that's about the only thing. for example, x32 gets access to 64bit registers
> when working with 64bit types (long long) and the tuple is x86_64-pc-linux-
> gnu.
On Friday, September 16, 2011 15:09:52 Thomas Sachau wrote:
> Mike Frysinger schrieb:
> > On Friday, September 16, 2011 04:28:24 Stratos Psomadakis wrote:
> >> Is a x86/amd64/x32 multilib profile just going to provide toolchain
> >> support for x32 binaries (like x86 in a x86/amd64 multilib profile
Mike Frysinger schrieb:
> On Friday, September 16, 2011 04:28:24 Stratos Psomadakis wrote:
>> Is a x86/amd64/x32 multilib profile just going to provide toolchain
>> support for x32 binaries (like x86 in a x86/amd64 multilib profile), or
>> do we want a 'full' x32 profile, where every package is bui
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
On 09/16/11 20:32, Mike Frysinger wrote:
> On Friday, September 16, 2011 11:06:25 Markos Chandras wrote:
>> On 09/16/11 10:58, Stratos Psomadakis wrote:
>>> On 09/16/2011 10:48 AM, Michał Górny wrote:
On Thu, 15 Sep 2011 16:35:55 -0400 Mike Frys
On 09/16/2011 06:06 PM, Markos Chandras wrote:
> On 09/16/11 10:58, Stratos Psomadakis wrote:
> > On 09/16/2011 10:48 AM, Michał Górny wrote:
> >> On Thu, 15 Sep 2011 16:35:55 -0400 Mike Frysinger
> >> wrote:
> >>
> PS why not merge all x86 abis into one keyword? because
> x86_32 x86_64
On Friday, September 16, 2011 11:06:25 Markos Chandras wrote:
> On 09/16/11 10:58, Stratos Psomadakis wrote:
> > On 09/16/2011 10:48 AM, Michał Górny wrote:
> >> On Thu, 15 Sep 2011 16:35:55 -0400 Mike Frysinger wrote:
> PS why not merge all x86 abis into one keyword? because
> x86_32 x86
On Friday, September 16, 2011 12:01:43 Mike Frysinger wrote:
> On Friday, September 16, 2011 10:06:07 Michał Górny wrote:
> > But doesn't switching mean we're going to hit LFS PITA once again?
>
> LFS hasnt really been a pain in a long while. but it's something worth
> raising on the x32 lists (w
On Friday, September 16, 2011 04:28:24 Stratos Psomadakis wrote:
> Is a x86/amd64/x32 multilib profile just going to provide toolchain
> support for x32 binaries (like x86 in a x86/amd64 multilib profile), or
> do we want a 'full' x32 profile, where every package is built by default
> as x32 code?
On Friday, September 16, 2011 10:06:07 Michał Górny wrote:
> But doesn't switching mean we're going to hit LFS PITA once again?
LFS hasnt really been a pain in a long while. but it's something worth
raising on the x32 lists (which i'll do) since x32 has native 64bit support
(uint64_t == %rax).
On Friday, September 16, 2011 09:36:32 Donnie Berkholz wrote:
> understanding is that it probably makes sense to switch to x32 no matter
> what you're using now (x86 or amd64).
x32 needs a 64bit processor, so x86 cant go away as it's the only ABI that can
run on 32bit processors
but for 64bit pr
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
On 09/16/11 10:58, Stratos Psomadakis wrote:
> On 09/16/2011 10:48 AM, Michał Górny wrote:
>> On Thu, 15 Sep 2011 16:35:55 -0400 Mike Frysinger
>> wrote:
>>
PS why not merge all x86 abis into one keyword? because
x86_32 x86_64 x86_x32 are
On Fri, 16 Sep 2011 08:36:32 -0500
Donnie Berkholz wrote:
> On 15:34 Thu 15 Sep , Mike Frysinger wrote:
> > ive converted my system over to x86/amd64/x32 multilib for funs.
> > but i can see how some people wont want all three all the time. so
> > the question is how we want to make this ava
On 15:34 Thu 15 Sep , Mike Frysinger wrote:
> ive converted my system over to x86/amd64/x32 multilib for funs. but i can
> see how some people wont want all three all the time. so the question is how
> we want to make this available to users at the release/profile level.
>
> background: x3
On 09/15/2011 10:34 PM, Mike Frysinger wrote:
> ive converted my system over to x86/amd64/x32 multilib for funs. but i can
> see how some people wont want all three all the time. so the question is how
> we want to make this available to users at the release/profile level.
>
> background: x32 i
On Fri, 16 Sep 2011 10:58:01 +0300
Stratos Psomadakis wrote:
> On 09/16/2011 10:48 AM, Michał Górny wrote:
> > On Thu, 15 Sep 2011 16:35:55 -0400
> > Mike Frysinger wrote:
> >
> >>> PS why not merge all x86 abis into one keyword? because x86_32
> >>> x86_64 x86_x32 are only abis of x86. Also we
On 09/16/2011 10:48 AM, Michał Górny wrote:
> On Thu, 15 Sep 2011 16:35:55 -0400
> Mike Frysinger wrote:
>
>>> PS why not merge all x86 abis into one keyword? because x86_32
>>> x86_64 x86_x32 are only abis of x86. Also we dont have different
>>> keywords for different mips abis (64bit and 32bit o
On Thu, 15 Sep 2011 16:35:55 -0400
Mike Frysinger wrote:
> > PS why not merge all x86 abis into one keyword? because x86_32
> > x86_64 x86_x32 are only abis of x86. Also we dont have different
> > keywords for different mips abis (64bit and 32bit ones)
>
> that'd be nice :)
Seems even acceptabl
On Thursday, September 15, 2011 17:03:07 Michał Górny wrote:
> On Thu, 15 Sep 2011 16:33:48 -0400 Mike Frysinger wrote:
> > On Thursday, September 15, 2011 16:12:00 Michał Górny wrote:
> > > On Thu, 15 Sep 2011 15:34:06 -0400 Mike Frysinger wrote:
> > > > KEYWORDS wise, i'd like to avoid having to
On Thu, 15 Sep 2011 16:33:48 -0400
Mike Frysinger wrote:
> On Thursday, September 15, 2011 16:12:00 Michał Górny wrote:
> > On Thu, 15 Sep 2011 15:34:06 -0400 Mike Frysinger wrote:
> > > KEYWORDS wise, i'd like to avoid having to add "x32" everywhere.
> > > instead, reusing "amd64". only downsid
On Thursday, September 15, 2011 16:00:14 Alexey Shvetsov wrote:
please dont top post
> Is it accepted for merge into kernel mainline for 3.2?
no. i was just being optimistic. i'm running 3.1-rc4 atm with a smallish
patch to make it work.
> Actualy this abi looks like n32 mips abi.
yeah, a l
On Thursday, September 15, 2011 16:12:00 Michał Górny wrote:
> On Thu, 15 Sep 2011 15:34:06 -0400 Mike Frysinger wrote:
> > KEYWORDS wise, i'd like to avoid having to add "x32" everywhere.
> > instead, reusing "amd64". only downside is the existing USE=amd64
> > behavior, but we can address that b
On Thu, 15 Sep 2011 15:34:06 -0400
Mike Frysinger wrote:
> KEYWORDS wise, i'd like to avoid having to add "x32" everywhere.
> instead, reusing "amd64". only downside is the existing USE=amd64
> behavior, but we can address that by making MULTILIB_ABIS a
> USE_EXPAND (i think this came up before
Hi all!
Is it accepted for merge into kernel mainline for 3.2?
Actualy this abi looks like n32 mips abi.
PS why not merge all x86 abis into one keyword? because x86_32 x86_64
x86_x32 are only abis of x86. Also we dont have different keywords for
different mips abis (64bit and 32bit ones)
On
ive converted my system over to x86/amd64/x32 multilib for funs. but i can
see how some people wont want all three all the time. so the question is how
we want to make this available to users at the release/profile level.
background: x32 is a new ABI that runs on 64bit x86_64 processors. see
37 matches
Mail list logo
