Generally, if one is installing 32 bit libraries, it is because one cannot build said package for 64 bit.

lib32 is a far worse hack, and a violation of the AMD64 ABI. Either do multilib properly from day one, or don't do it - don't change your mind on it and try and shoehorn it in later.

Yeap :)

I dont-have to worry about this because there are /lib64 and /usr/lib64 symlinks to the /lib and /usr/lib which preserve the AMD64 ABI ;).

Also, take a look (just for curiosity) to other major Linux distributions how they do and brake AMD64 ABI ;).

Just a note on this now that I see it. You can actually run a 32-bit kernel with more than 4 GB of RAM, however in order to do this you must build the kernel specifically for your machine. For example I have a Core 2 Quad, and I must build the kernel for Core 2/Xeon and enable Huge Mem support.

As for running 32-bit on 64-bit, I find it quite confusing and difficult to work with. Therefore I usually stick with 32-bit. I'll try to figure it out when I have more time, exactly how it works and what not to do as I've had lots of strange issues.

PAE is a nasty hack with a performance penalty. If you're going to use more than 4GB, you really should be using x86-64. Otherwise just stick with the 4GB max for 32 bit.

It's not really that confusing.

x86-64 can run 32 bit code at native speed. There are basically four ways of running 32 bit code on AMD64:

1) chroot - Nobody does this anymore, as it's rather OTT.

2) The Debian way - enough said (Debian is really a pure lib distribution, with some symlinks for convenience, but you end up with a mess in lib of 32 and 64 bit).

3) lib32 - Not particularly popular. Flies in the face of pretty much where everyone expects 32 bit libraries to go.

4) lib64 - Used by pretty much everyone else (Red Hat/ Fedora, SuSE and Mandriva). Apart from the AMD64 ABI (as I've mentioned earlier), this is also specified as the correct location in the FHS. 64 bit libraries are put into lib64, 32 bit libraries go to lib. Maintains compatibility with x86 better (this was intentional on AMD's part).

(Gentoo are a bit odd here, in that they use lib32 and lib64 - they try to put 32 bit libraries in lib32, and 64 bit ones in lib64, and symlink /usr/lib to the running system).

So, on Slamd64 and other lib64 distributions, you are provided with a minimal set of 32 bit libraries in lib (generally, enough to run those 32 bit packages that require you to have 32 bit libraries in the first place). Basically, the general idea here of installing 32 bit software on 64 bit is that it should Just Work(TM) without having to muck about rearranging, rebuilding, etc the 32 bit libraries from their traditional home in lib.

Well, over the past few weeks I've been working on getting 64-bit MIPSel tool chains built. So far I've completed both multilib and pure, and I have a choice of creating either a multilib (actually multibin with /bin, /bin64, /lib, /lib64, /usr/libexec and /usr/libexec64 is what I've been thinking of) or a pure distribution (or both :)).

So far I'm going with the latter because of its simplicity and lack of need for 32-bit compatibility (there is not much legacy 32-bit closed source software on MIPS), but I've also built a multilib tool chain to be able to create that multibin distribution from if it's really needed. I've been using Bluewhite64 12.0 as my distribution of choice on my x86_64 computer and I've only built a few packages that install their libraries to (/usr)/lib64 by default. So it's not a given that it's unsuited to real world usage, not to the extent that Slamd64 is superior by design.

I've had very few problems with it actually. This could of course be a side-effect of the fact that I have Slackware 12.0 running on my laptop where I have access to Flash e.a. if I really need it (which I don't). I would rather see Gnash succeed than accommodate for 32-bit closed source or free software that appears to be broken as 64-bit x86 binaries. I'd rather fix the source code and recompile or discard it completely.

I'm going to install Slamd64 12.0 soon on the other partition that I've reserved on my hard drive and build packages just to see how the two compare. I don't think it will matter that much in the end. I'd say use Slamd64 if you want/require Slackware compatibility and Bluewhite64 if you just don't care and want a clean 64-bit x86 system in which you'll have to work just a little more to get 32-bit x86-only software (such as Slackware packages or closed source) to work.

I don't think Bluewhite64's way of doing things is wrong or violates the FHS (which isn't entirely clear or very complete either) because the FHS explicitly allows for /lib64 to be a symlink to /lib (and vice versa). Also Bluewhite64 probably doesn't care as much about 32-bit x86 compatibility (which IMHO is overrated) as Slamd64 does. That doesn't mean that one is wrong and the other's right. They're different solutions to different problems.

Slamd64 accommodates for Slackware packages directly and Bluewhite64 provides compatibility packages. That's the only difference for me as someone who's struggling with the same problem on a different architecture ;-). And to the person who mentioned PAE, why don't you run a 64-bit kernel with 32-bit userland if you need access to more than 4 GB RAM? That's a perfectly valid configuration on most other architectures, why wouldn't it be on x86?

Needless performance loss - on x86-64, there is an actual advantage to a 64 bit userspace (AMD64 is rather unique in that respect).