[Gllug] Kernel compile taking forever...!

[John Edwards]

On Wed, Feb 02, 2005 at 09:40:52AM +0000, Jack Bertram wrote:
> * Nix <nix at esperi.org.uk> [050202 00:45]:
>> On Tue, 1 Feb 2005, Jack Bertram murmured woefully:
>>> 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 ;)
> 
> Hmmm.  What do you mean? - the rest of your email seems to suggest that
> you don't need a chroot.
> 
> Surely I can't run 64bit code without a 64bit kernel, and I can't run
> one of those in a chroot.
> 
> I suppose I could install AMD64 and set up a 32-bit chroot, but what is
> a 32-bit chroot?  Could I then run OO.o?

You can run a kernel compiled for AMD64 on a machine with normal 32bit 
libraries and programs. I'm using Debian 3.1 with custom 64bit kernel, 
though you can use the standard deb package ones. Normal install worked, 
no chroot was needed and Openoffice is fine.

Recompiling everything as 64 bit is a different matter and not something 
I've tried yet.

I thought a chroot was need in the Debian AMD64 port because they placed 
the 64 bit libraries in the "lib" directories instead of "lib64". So 
programs biult for a 32 bit machine look for their 32 bit libraries but 
find 64 bit ones.

There was a nice long flame war on the subject on the debian-devel mailing 
list a few months ago. The subject line was something like "serious bug 
found in ftpmasters".

I'm not sure that other distros (SuSE and RedHat) need this. Other ports 
of Debian to mixed 32/64 bit architectures certain don't do this.


>> 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.
> 
> These seems to suggest that they're completely compatible as long as
> programs don't use assembler?

Seems to be that way.


>> (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.)
> 
> 64-bit code runs slower on an UltraSPARC than 32-bit code?

In general I believe that is true.


-- 
#---------------------------------------------------------#
|       John Edwards    Email: John.Edwards at uk.com        |
|                                                         |
| A. Because it breaks the logical sequence of discussion |
| Q. Why is top posting bad ?                             |
#---------------------------------------------------------#
-- 
Gllug mailing list  -  Gllug at gllug.org.uk
http://lists.gllug.org.uk/mailman/listinfo/gllug