[Gllug] Kernel compile taking forever...!

[Nix]

On Tue, 1 Feb 2005, Jack Bertram murmured woefully:
> * Martin A. Brooks <martin at hinterlands.org> [050201 22:36]:
>> Jack Bertram wrote:
>> 
>> >I'm compiling for k7 only.
>> 
>> Probably a silly question, but why are you compiling for k7 when you 
>> have a k8 class processor?
> 
> Because I've upgraded an existing system and didn't want to mess around
> with libraries etc.

The kernel is a layer below that; further, all 32-bit Linux C code has
a compatible ABI, so you can easily compile each object file in a program
for a different 32-bit Intel CPU and it'll all work seamlessly.

>                     Besides, I've heard that there are many programs
> that don't work properly under 64bit (e.g., openoffice).

It's not 64-bitness that hurts that, but the fact that like Mozilla, it
has some assembler in it :(

>                                                           So I thought I
> would get this system working properly and then try an AMD64
> installation on a new partition.

I'd use a chroot ;)

Once you hit userspace, the 32- and 64-bit stuff is basically separate
universes. They split apart down inside the kernel, where an indirection
layer transforms 32-bit system call into the kernel's native 64-bit
ones, and all the code above that inherits that `bitness'.

So you need separate userspaces, pretty much: the filesystem is shared,
and interprocess communication can reach across the divide, but each
process is either 32- or 64-bit, never a mixture.

(I've got a mixed 32 and 64-bit SPARC/Linux userspace here: unlike on
AMD64, there are significant speed costs in compiling stuff as 64-bit on
UltraSPARC, so the majority of my userspace is 32-bit. The XEmacs I'm
typing this mail in is 64-bit, though.)

-- 
`Blish is clearly in love with language. Unfortunately,
 language dislikes him intensely.' --- Russ Allbery
-- 
Gllug mailing list  -  Gllug at gllug.org.uk
http://lists.gllug.org.uk/mailman/listinfo/gllug