32bit-userland on Gentoo amd64
For the past couple of weeks, I’ve been working on getting 32bit-userland working on Gentoo amd64. It’s at least partly working now; it boots, you can log in, and I’m in the process of emerging gnome.
However, it’s not a smooth road. I had to use catalyst to make my own stages. No amount of massaging or editing or copying or screaming got me from a 64-bit stage3 to a 32bit-userland. In addition, there’s something wrong with my toolchain somehwere. I can’t build sandbox, for example, and had to use a binpkg from my 64-bit system. Also, the kernel fails to build it’s config programs, so I can’t configure a kernel.
Finally, there are a number of broken packages; that is, packages that detect in some way or another what bitness they think you’re running and then use ASM coded for that. This, obviously, fails. Fortunately, this is so far only 3 packages: glib, libgcrypt, and mesa. We’ll see how many more I hit before I get a working system.
Just a note: I’m not posting any of my profiles yet. It’s not yet working, and it’s not for faint of heart. If you are really interested, give me a ping on IRC and I’ll see if I can help you. Otherwise, just wait until I can lick it into shape.
I remember blubb working on this a few years back; I think it was psmisc that had huge problems with that, and the author not wanting to even think about running 32-bit userland on a 64-bit kernel.
Good luck
You might like to check out http://dev.gentoo.org/~kanaka/auto-multilib/
I’ve been running a 32-bit userland with a 64-bit kernel for a while now, without many issues – to make life easier, my initrd calls “exec pivot_root /sysroot /usr/bin/linux32 /sbin/init” at the end, so unless I tell a program otherwise, everything actually thinks that it’s running on a 32-bit system – even ‘uname -m’ outputs ‘i686′. I also have a 64-bit chroot on the system, which I use to compile the kernel and external modules, because I didn’t want to bother with building a cross-compiler.
Hi
Just a question… what’s the motivation for doing this? I can see only one real practical use for this:
- save diskspace because binaries are smaller – or –
- save memory because 32bit apps tend to use less memory
The reason I’m asking – it starts to be common that new pc’s are equipped with 3-4 gb of ram, and this figure will increase. This means that 64bit OS is a must (at least on the kernel side).
So your motivation can’t be 32bit only apps right?
Cheers and good luck
Yes, that would be easy. But that’s not what I wanted. I wanted to see if I could make a multilib system with a 32bit userland, that portage could keep up-to-date with no problems.
My main motivation was just to see if I could do it. The secondary motivation is memory. I have a 32-bit box at work that uses 1/3 the memory of my 64-bit box for essentially the same working set, and I’m wondering if a 32bit userland would help with that. There’s also speed. AMD boxes are generally faster in 64-bit mode; intel boxes (which is what I have these days) are generally faster in 32-bit mode (except for the very newest ones). Finally, there’s compatibility. I want to be able to run Neverwinter Nights, for example, and keeping it working on a 64-bit ~arch box is almost impossible.
Mostly, tho, it’s just to see if I can do it.
@Benjamin Shindler — I would have shared your view two years ago, but at this point I am sick of trying to run in a swimming pool full of molasses, with all the 32-bit apps that are still broken on LP64.
Solaris has taken the lazy approach since the beginning, and still does. They have three kinds of kernel and four kinds of userland binary:
kernel
*sparcv9 (64-bit)
*amd64 (64-bit)
i386 (32-bit)
userland
sparcv9 (64-bit)
*sparc (32-bit)
amd64 (64-bit)
*i386 (32-bit)
The choices without a ‘*’ next to them are the “less equal” architectures, where more stuff is broken. Solaris isn’t as performant or reliable on a 32-bit x86 machine as on a 64-bit, and Sun sells no 32-bit hardware. But almost all the userland including the JRE is compiled 32-bit on both x86 and sparc.
If you want to build something 64-bit, you pass special flags to the C compiler, and it is just like Linux, it grabs separate libraries and links with no 32-bit code all the way up to the syscall boundary. Everything built this way gets installed in bastard-stepchild directories like /lib/sparcv9, /usr/lib/sparcv9, /usr/bin/sparcv9 on sparc, or /lib/amd64, /usr/lib/amd64, /usr/bin/amd64 on x86, so that some 10-year-old legacy 32-bit build of Oracle that loses its shit if anything is even slightly odd will not even notice these 64-bit programs exist. They are not normally even in the PATH of a Solaris user, so you will be using entirely 32-bit userland unless you go out of your way to request 64-bit version, usually because you want a bigger memory core image or something.
At the same time it’s very easy to ship an amd64 VirtualBox and expect that /usr/lib/amd64/libX11.* will always exist for it (though it’ll probably talk to a 32-bit X server
.
This way, bloody bloatware like Firefox and GNOME and Xorg experiences regressions less often. and more importantly, to them, all your old proprietary software keeps working.
I want to run some proprietary software, like Youtube and Airfoil and Acrobat Reader, and they can scarcely be bothered to keep the 32-bit linux version working—if there’s a 64-bit version, it’ll be less stable guaranteed. and I know there are “alternatives” but in practice the real “alternative” is that my housemates will get frustrated and unplug my Linux box and plug in their macbook into the TV/stereo instead, and they don’t want to discuss software freedom at all until they find themselves with a Region 2 DVD they can’t play. so, yes, I’m apologizing for wanting to run proprietary software, but also I want to spend the minimum amount of time getting the proprietary software working so I can do something else, and I would rather not achieve that by putting my television under the control of Mac OS.
I do not want to be nagged by 64-bit bullshit, whether it’s regressions in bloated free software, or proprietary apps that are 10x harder to get working than they are for everyone else. At the same time I want all 8GB RAM available, and a 64-bit toolchain when I want it, and ability to run 64-bit guest operating systems under virtualbox or vmware server. The Solaris way is hideous and crass, but for me I want amd64 to be a value-add only. I want to conserve my zealotry for something worthwhile and let someone else pour their effort into the ongoing LP64 disaster.
What’s going on is, developers release 32-bit binaries because they know much of their audience is still 32-bit, and this way they can make one release. If they worked on 64-bit, they’d have to make two releases. so, God willing, the whole LP64 mess will go away when there are no 32-bit chips left, provided we are ABLE to give the impatient user a way to arrange that he can run a 64-bit program instantly wihout noticing, which 64-bit kernel 32-bit userland _does_, and 64-bit kernel 64-bit userland does not because you have to choose between an unstable machine with missing programs or an all-32bit machine. Secondly motherfucking intel is still releasing 32-bit Atom chips for those stupid laptops! The Atom chips on the desktop boards are 64-bit, but not the laptop Atom’s. All CPU’s should be 64-bit by now.