Gentoo experimental release of native x32

[Mike Frysinger]

you can find the stage3 here:
http://dev.gentoo.org/~vapier/x32/stage3-amd64-x32-20111209.tar.xz

you don't need to boot Gentoo to use it ... just unpack it into some
location, mount the standard pseudo filesystems in it, then chroot and
it should work fine

to install new packages, just do:
emerge <pkg>
-mike

[Octoploid]

Thanks. It works fine. Can you please also post
profiles/default/linux/amd64/10.0/x32/ ?

--
controlled by gamma light

[Octoploid]

Ah, I see the profile has hit the official portage tree this
morning. Thanks.

[Stuart Shelton]

Kernel 3.4 with x32 support has now been released, so this could be used on a live system.  Quick query, though - are we tied to /lib32, /libx32, and /lib64 with /lib being a symlink?  IMHO, those first two are too similar and could be easily confused.  Is there any option within portage which would allow, for example, the use of /lib (32-bit), /lib32 (x32), and /lib64 (64-bit) - I believe this is the scheme used by SGI/MIPS for o32/n32/64 ABIs.  Debian/Ubuntu only currently use /lib (32-bit) and /lib64, so this seems like a more likely future standard than the layout this stage3 takes... any thoughts?

Cheers,

Stuart

[H. Peter Anvin]

The "official" ABI recommendation is /lib, /libx32, and /lib64. Please
don't use /lib32 to mean x32, that would be really messy.

-hpa

[Mike Frysinger]

On Mon, May 21, 2012 at 2:56 PM, Stuart Shelton wrote:
> Kernel 3.4 with x32 support has now been released, so this could be used on
> a live system.

not yet. that tarball is built with the old ABI ... the stuff merged
into mainline changed. i've been waiting for the linux-3.4 and
glibc-2.16 releases to rebuild things as my current env keeps
producing a bash that segfaults, and i don't really know why.

> Quick query, though - are we tied to /lib32, /libx32, and
> /lib64 with /lib being a symlink?  IMHO, those first two are too similar and
> could be easily confused.  Is there any option within portage which would
> allow, for example, the use of /lib (32-bit), /lib32 (x32), and /lib64
> (64-bit) - I believe this is the scheme used by SGI/MIPS for o32/n32/64
> ABIs.  Debian/Ubuntu only currently use /lib (32-bit) and /lib64, so this
> seems like a more likely future standard than the layout this stage3
> takes... any thoughts?

i don't think lib32 and libx32 are that confusing, but that's me.
we've got the SYMLINK_LIB knob to control whether /lib is for 32bit or
a symlink to /lib64 (and /lib32 is for 32bit). the long term plan is
to convert away from the /lib32 stuff, but i have to be _really_
careful to avoid breaking live systems.

i plan on having the x32 profiles defaulting to SYMLINK_LIB=no, so
it'd use /lib /libx32 /lib64.
-mike

[Mike Frysinger]

On Mon, May 21, 2012 at 3:10 PM, H. Peter Anvin wrote:
> The "official" ABI recommendation is /lib, /libx32, and /lib64.  Please
> don't use /lib32 to mean x32, that would be really messy.

he's talking about x86/32bit, not x32. Gentoo only uses /libx32 for x32 libs.
-mike

[H.J. Lu]

On Mon, May 21, 2012 at 1:36 PM, Mike Frysinger <vap...@gmail.com> wrote:
> On Mon, May 21, 2012 at 2:56 PM, Stuart Shelton wrote:
>> Kernel 3.4 with x32 support has now been released, so this could be used on
>> a live system.
>
> not yet.  that tarball is built with the old ABI ... the stuff merged
> into mainline changed.  i've been waiting for the linux-3.4 and
> glibc-2.16 releases to rebuild things as my current env keeps
> producing a bash that segfaults, and i don't really know why.

x32 system call numbers were changed a little bit. You need
to recompile everything with the kernel 3.4 header files. I also
change x32 default ABI to GLIBC_2.16. My current x32 changes
are on hjl/x32/master branch. It should be very close to the final
one.

--
H.J.

[Mike Frysinger]

On Mon, May 21, 2012 at 4:49 PM, H.J. Lu wrote:

> On Mon, May 21, 2012 at 1:36 PM, Mike Frysinger wrote:
>> On Mon, May 21, 2012 at 2:56 PM, Stuart Shelton wrote:
>>> Kernel 3.4 with x32 support has now been released, so this could be used on
>>> a live system.
>>
>> not yet.  that tarball is built with the old ABI ... the stuff merged
>> into mainline changed.  i've been waiting for the linux-3.4 and
>> glibc-2.16 releases to rebuild things as my current env keeps
>> producing a bash that segfaults, and i don't really know why.
>
> x32 system call numbers were changed a little bit.  You need
> to recompile everything with the kernel 3.4 header files.

i'm aware. it didn't seem to help.

> I also
> change x32 default ABI to GLIBC_2.16. My current x32 changes
> are on hjl/x32/master branch.   It should be very close to the final
> one.

ok ... last time i looked at the glibc branch, it was out of date, but
that was before the recent merge push. i'll try again.
-mike

[Stuart Shelton]

Okay, cool - I wasn't aware that there was an official recommendation as to how this should be handled. I assumed that each distro would do it's own thing (plus ça change...)

[Mike Frysinger]

On Mon, May 21, 2012 at 5:25 PM, Mike Frysinger wrote:
> On Mon, May 21, 2012 at 4:49 PM, H.J. Lu wrote:
>> On Mon, May 21, 2012 at 1:36 PM, Mike Frysinger wrote:
>>> On Mon, May 21, 2012 at 2:56 PM, Stuart Shelton wrote:
>>>> Kernel 3.4 with x32 support has now been released, so this could be used on
>>>> a live system.
>>>
>>> not yet.  that tarball is built with the old ABI ... the stuff merged
>>> into mainline changed.  i've been waiting for the linux-3.4 and
>>> glibc-2.16 releases to rebuild things as my current env keeps
>>> producing a bash that segfaults, and i don't really know why.
>>
>> x32 system call numbers were changed a little bit.  You need
>> to recompile everything with the kernel 3.4 header files.
>
> i'm aware.  it didn't seem to help.

seems there is something a bit more than just syscall numbers. the
glibc-2.15 source tree + patch i have still segfaulted with bash
(simpler stuff worked). installing latest glibc git fixed that.
-mike