Pure 64 bootloaders

Pure 64 bootloaders

[Jim Gifford]

I have been working on a project to create a Pure 64 bit distro of 
linux, nothing 32 bit in the system. I can accomplish that with no 
issues pretty much on all platforms, with the exception of the 
bootloaders. It just seems odd, that all the bootloaders seem to have 
gcc -m32 in their makefiles.

Silo on the Sparc has gcc -m32
Grub on the x86 platforms has gcc -m32
 
The only one that builds and works is Lilo, which most people are moving 
away from.

So for my question, why does a bootloader have to be 32bit?
Anyone got 64 bit bootloaders for Sparc or x86_64 machines?
Are there technical limitations that bootloaders can't be 64 bit?
If we can't have a pure64 environment, why does the Kernel support it?

Thank you all for taking you time to respond.

-- 
----
Jim Gifford
maillist@jg555.com

Re: Pure 64 bootloaders

[Jeff Garzik]

On Sat, Sep 10, 2005 at 12:42:06AM -0700, Jim Gifford wrote:
> I have been working on a project to create a Pure 64 bit distro of 
> linux, nothing 32 bit in the system. I can accomplish that with no 
> issues pretty much on all platforms, with the exception of the 
> bootloaders. It just seems odd, that all the bootloaders seem to have 
> gcc -m32 in their makefiles.
> 
> Silo on the Sparc has gcc -m32
> Grub on the x86 platforms has gcc -m32
> 
> The only one that builds and works is Lilo, which most people are moving 
> away from.
> 
> So for my question, why does a bootloader have to be 32bit?
> Anyone got 64 bit bootloaders for Sparc or x86_64 machines?
> Are there technical limitations that bootloaders can't be 64 bit?
> If we can't have a pure64 environment, why does the Kernel support it?

It depends on the mode the CPU is in, at boot time.  Also, there are size
constraints, as 64-bit code is usually larger.

There's nothing stopping you from writing a bootloader that immediately
put the CPU into 64-bit mode, and then proceeds from there...

	Jeff

Re: Pure 64 bootloaders

[David S. Miller]

From: Jim Gifford <maillist@jg555.com>
Date: Sat, 10 Sep 2005 00:42:06 -0700

> So for my question, why does a bootloader have to be 32bit?
> Anyone got 64 bit bootloaders for Sparc or x86_64 machines?

You can make SILO 64-bit, but it would just be a lot
of work and would just result in a SILO that, unlike
current SILO, would only work on UltraSPARC machines.

32-bit SILO, on the other hand, can work on any Sparc system.

There really is no advantage, and known disadvantages, to
making SILO 64-bit.

Re: Pure 64 bootloaders

[Jim Gifford]

David S. Miller wrote:

>You can make SILO 64-bit, but it would just be a lot
>of work and would just result in a SILO that, unlike
>current SILO, would only work on UltraSPARC machines.
>
>There really is no advantage, and known disadvantages, to
>making SILO 64-bit.
>  
>
If I have a system that is a Pure64 environment, I try to compile Silo, 
it will not function. Since there is no support for 32 bit, how would I 
be able to use it.

Isn't there a way to compile the programs necessary as 64bit but the 
actual mbr or .b files depending on your architecture be 32 bit. I

In the case of Silo, it compiles, but when you run silo -f, when you 
reboot, it Starts Silo, then gives, Program Terminiated in OBP. Which 
now makes the computer useless, unless you have a 32 bit build of silo 
standing around.

Also in the case of Silo, if you try to compile it on a modern tool 
chain, the .b files it generates don't work, which I have reported 
upstream. Modern toolchain = binutils 2.16.1, gcc 3.4.4, and glibc 2.3.5.

For the Sparc64 builds, I'm starting to look at using OBP to do the booting.

-- 
----
Jim Gifford
maillist@jg555.com

Re: Pure 64 bootloaders

[David S. Miller]

From: Jim Gifford <maillist@jg555.com>
Date: Sun, 11 Sep 2005 09:33:26 -0700

> David S. Miller wrote:
> 
> >You can make SILO 64-bit, but it would just be a lot
> >of work and would just result in a SILO that, unlike
> >current SILO, would only work on UltraSPARC machines.
> >
> >There really is no advantage, and known disadvantages, to
> >making SILO 64-bit.
> >  
>
> If I have a system that is a Pure64 environment, I try to compile Silo, 
> it will not function. Since there is no support for 32 bit, how would I 
> be able to use it.

You'll need some minimal 32-bit libraries sitting around in order
to build it, sorry.

For performance reasons alone I would _never_ condone a purely
64-bit userland.  It's simply a total lose from a performance
perspective, unlike some other platforms such as amd64 which
eradicate most of the 64-bit performance loss due to the gain
in available cpu registers compared to 32-bit x86.

Re: Pure 64 bootloaders

[David S. Miller]

From: Jim Gifford <maillist@jg555.com>
Date: Sun, 11 Sep 2005 09:33:26 -0700

> For the Sparc64 builds, I'm starting to look at using OBP to do the booting.

OBP cannot boot because it doesn't understand the ext2
filesystem, and therefore cannot get at the image.

The only thing you can do is netboot kernel images converted
to a.out format using the elf2aout tool.

Stop fighting city hall and work on fixing SILO to support
a 64-bit build if you want, instead of all of these hacks.
:-)

Re: Pure 64 bootloaders

[Andi Kleen]

Jim Gifford <maillist@jg555.com> writes:

> I have been working on a project to create a Pure 64 bit distro of
> linux, nothing 32 bit in the system. I can accomplish that with no

Hopefully you're using /lib64 for that, otherwise your
packages will be incompatible to everybody else and not 
FHS compliant. If you don't please don't submit any 
patches to hardcode this to upstream packages.

> issues pretty much on all platforms, with the exception of the
> bootloaders. It just seems odd, that all the bootloaders seem to have
> gcc -m32 in their makefiles.

Not only the boot loaders, but the kernel needs a -m32
compilers/toolset to build the bzImage unpacker. There were some plans
to change that, but it hasn't happened so far.
> 
> Silo on the Sparc has gcc -m32
> Grub on the x86 platforms has gcc -m32
>  The only one that builds and works is Lilo, which most people are
> moving away from.
> 
> So for my question, why does a bootloader have to be 32bit?
> Anyone got 64 bit bootloaders for Sparc or x86_64 machines?

kexec is essentially a 64bit boot loader, but you need
linux running before so it has a little bootstrap problem.

I believe the folks at http://www.codegen.com got one too, but
it's proprietary.

The problem is that there is currently no defined protocol
for passing data to the 64bit part of the kernel, so while
it would be possible to write a boot loader that starts
a 64bit kernel it would be very kernel version dependent.

-Andi

Re: Pure 64 bootloaders

[Jeff Garzik]

Andi Kleen wrote:
> Jim Gifford <maillist@jg555.com> writes:
> 
> 
>>I have been working on a project to create a Pure 64 bit distro of
>>linux, nothing 32 bit in the system. I can accomplish that with no
> 
> 
> Hopefully you're using /lib64 for that, otherwise your
> packages will be incompatible to everybody else and not 
> FHS compliant. If you don't please don't submit any 
> patches to hardcode this to upstream packages.

/lib64 is an awful scheme.  I'd avoid it.

Consider what happens in the existing scenario where you have capability 
to run both IA64 and x86-64 binaries on the same system.


> The problem is that there is currently no defined protocol
> for passing data to the 64bit part of the kernel, so while
> it would be possible to write a boot loader that starts
> a 64bit kernel it would be very kernel version dependent.

Good point.

	Jeff

Re: Pure 64 bootloaders

[Chris Wedgwood]

On Sat, Sep 10, 2005 at 04:39:00AM -0400, Jeff Garzik wrote:

> /lib64 is an awful scheme.  I'd avoid it.

I'd like to see people move away from it before it gets too entrenched
too.

What does ppc64 and sparc64 use btw?

Re: Pure 64 bootloaders

[David S. Miller]

From: Chris Wedgwood <cw@f00f.org>
Date: Sat, 10 Sep 2005 09:34:46 -0700

> On Sat, Sep 10, 2005 at 04:39:00AM -0400, Jeff Garzik wrote:
> 
> > /lib64 is an awful scheme.  I'd avoid it.
> 
> I'd like to see people move away from it before it gets too entrenched
> too.
> 
> What does ppc64 and sparc64 use btw?

The same.

Re: Pure 64 bootloaders

[Joe Bob Spamtest]

Chris Wedgwood wrote:
>> /lib64 is an awful scheme.  I'd avoid it.
> I'd like to see people move away from it before it gets too entrenched
> too.

agreed -- as far as i'm concerned the 32 bit libraries are there for 
compatibility's sake and should be in /lib/compat/<subarch> instead of 
/lib. the native libraries should be in /lib instead of /lib64. lib64 
should just go away!

but then again, nobody asked for *my* input before this fhs spec came 
out, so ...

-kelsey

Re: Pure 64 bootloaders

[David S. Miller]

From: Joe Bob Spamtest <joebob@spamtest.viacore.net>
Date: Mon, 12 Sep 2005 14:32:05 -0700

> Chris Wedgwood wrote:
> >> /lib64 is an awful scheme.  I'd avoid it.
> > I'd like to see people move away from it before it gets too entrenched
> > too.
> 
> agreed -- as far as i'm concerned the 32 bit libraries are there for 
> compatibility's sake and should be in /lib/compat/<subarch> instead of 
> /lib. the native libraries should be in /lib instead of /lib64. lib64 
> should just go away!

64-bit isn't any more "native" than 32-bit on some 64-bit platforms.
32-bit is the default and most desirable userland binary format on
sparc64 for example.  So 32-bit programs on sparc64 are as "native" as
64-bit ones might be considered.

Re: Pure 64 bootloaders

[Joe Bob Spamtest]

David S. Miller wrote:
>>agreed -- as far as i'm concerned the 32 bit libraries are there for 
>>compatibility's sake and should be in /lib/compat/<subarch> instead of 
>>/lib. the native libraries should be in /lib instead of /lib64. lib64 
>>should just go away!
> 
> 64-bit isn't any more "native" than 32-bit on some 64-bit platforms.
> 32-bit is the default and most desirable userland binary format on
> sparc64 for example.  So 32-bit programs on sparc64 are as "native" as
> 64-bit ones might be considered.

that's true, i had forgotten about the sparc64 case. it really does slow 
down tremendously when used in pure 64 bit mode

i would imagine this not to be the case for most architectures though. 
possibly hppa is the same way. anyone with mips64 and ppc64 hardware out 
there have any input?

Re: Pure 64 bootloaders

[David S. Miller]

From: Joe Bob Spamtest <joebob@spamtest.viacore.net>
Date: Mon, 12 Sep 2005 15:02:03 -0700

> David S. Miller wrote:
> >>agreed -- as far as i'm concerned the 32 bit libraries are there for 
> >>compatibility's sake and should be in /lib/compat/<subarch> instead of 
> >>/lib. the native libraries should be in /lib instead of /lib64. lib64 
> >>should just go away!
> > 
> > 64-bit isn't any more "native" than 32-bit on some 64-bit platforms.
> > 32-bit is the default and most desirable userland binary format on
> > sparc64 for example.  So 32-bit programs on sparc64 are as "native" as
> > 64-bit ones might be considered.
> 
> that's true, i had forgotten about the sparc64 case. it really does slow 
> down tremendously when used in pure 64 bit mode

PPC64 is the same, as well as a few others are likely to
be in this boat as well.  The only known exception where
64-bit is a true win is x86_64.

> i would imagine this not to be the case for most architectures though. 
> possibly hppa is the same way. anyone with mips64 and ppc64 hardware out 
> there have any input?

See above.

Re: Pure 64 bootloaders

[Joe Bob Spamtest]

David S. Miller wrote:

> PPC64 is the same, as well as a few others are likely to
> be in this boat as well.  The only known exception where
> 64-bit is a true win is x86_64.

ia64 runs terrible in 32 bit mode. but i suppose that because
of the nature of ia64 it's really doing emulation anyways.
either way, ia64 was a big disappointment to just about everyone.

Re: Pure 64 bootloaders

[Lennart Sorensen]

On Mon, Sep 12, 2005 at 04:09:01PM -0700, Joe Bob Spamtest wrote:
> ia64 runs terrible in 32 bit mode. but i suppose that because
> of the nature of ia64 it's really doing emulation anyways.
> either way, ia64 was a big disappointment to just about everyone.

ia64 also wasn't an extension on an existing 32bit design the way sparc,
ppc, mips and x86_64 have done.

Is the alpha also pure 64bit?

Of course mips is extra fun in having two 32bit formats and one 64bit
format.

Len Sorensen

Re: Pure 64 bootloaders

[Joe Bob Spamtest]

Lennart Sorensen wrote:
> ia64 also wasn't an extension on an existing 32bit design the way sparc,
> ppc, mips and x86_64 have done.

yeah, the only differene here is that x86_64 performs a hell of a lot
better in 99% of cases where a 32 bit compile performs next to a 64 bit
compile. In the case of the other architectures the 64 bit modes are
extensions of sorts, used for scientific and/or large calculations which
benefit from 64-bit datatypes and transactions.

> Is the alpha also pure 64bit?

Alpha was designed 64-bit from the start. DEC did a lot of neat things
with the design of that processor -- it's a shame it went the way of the
dodo when ia64 was proposed.

> Of course mips is extra fun in having two 32bit formats and one 64bit
> format.

Fun stuff. Another good architecture that bit the ia64 bug and got
stung.

Re: Pure 64 bootloaders

[Kyle Moffett]

On Sep 13, 2005, at 13:00:16, Joe Bob Spamtest wrote:
>> Is the alpha also pure 64bit?
>
> Alpha was designed 64-bit from the start. DEC did a lot of neat  
> things with the design of that processor -- it's a shame it went  
> the way of the dodo when ia64 was proposed.

PowerPC was designed 64-bit from the start too!  It's just that the  
architecture design group also realized that there would be a demand  
for 32-bit CPUs, and so from the _64-bit_ system, they designed a 32- 
bit system whose entire instruction set would be forward-compatible  
to 64-bit systems when they came out.  That's why 32-bit PowerPC  
machine code and 64-bit PowerPC machine code are completely identical  
except that 64-bit CPUs also have a few opcodes to process 64-bit  
data and a few extra kernel-mode registers.

Cheers,
Kyle Moffett

--
I lost interest in "blade servers" when I found they didn't throw  
knives at people who weren't supposed to be in your machine room.
   -- Anthony de Boer

Re: Pure 64 bootloaders

[Lennart Sorensen]

On Tue, Sep 13, 2005 at 11:44:55PM -0400, Kyle Moffett wrote:
> PowerPC was designed 64-bit from the start too!  It's just that the  
> architecture design group also realized that there would be a demand  
> for 32-bit CPUs, and so from the _64-bit_ system, they designed a 32- 
> bit system whose entire instruction set would be forward-compatible  
> to 64-bit systems when they came out.  That's why 32-bit PowerPC  
> machine code and 64-bit PowerPC machine code are completely identical  
> except that 64-bit CPUs also have a few opcodes to process 64-bit  
> data and a few extra kernel-mode registers.

Hmm, so how does that fit with needing both 32 and 64bit libraries on a
ppc system?  It seems apple forgot the 64bit part of a library recently
in a security fix, or is that something more to do with their os than
the cpu?

Len Sorensen

Re: Pure 64 bootloaders

[Kyle Moffett]

On Sep 14, 2005, at 09:20:45, Lennart Sorensen wrote:
> On Tue, Sep 13, 2005 at 11:44:55PM -0400, Kyle Moffett wrote:
>
>> PowerPC was designed 64-bit from the start too!  It's just that the
>> architecture design group also realized that there would be a demand
>> for 32-bit CPUs, and so from the _64-bit_ system, they designed a 32-
>> bit system whose entire instruction set would be forward-compatible
>> to 64-bit systems when they came out.  That's why 32-bit PowerPC
>> machine code and 64-bit PowerPC machine code are completely identical
>> except that 64-bit CPUs also have a few opcodes to process 64-bit
>> data and a few extra kernel-mode registers.
>
> Hmm, so how does that fit with needing both 32 and 64bit libraries  
> on a
> ppc system?  It seems apple forgot the 64bit part of a library  
> recently
> in a security fix, or is that something more to do with their os than
> the cpu?

Well, if you want to pass 64-bit pointer values to a library, the  
library needs to have functions that take 64-bit values and use 64- 
bit operations on them, just like all the other archs :-D.  It also  
needs 32-bit compatibility functions for the old 32-bit-only  
programs.  On the other
hand, if you don't care about compatibility with 32-bit-pointer  
programs, you can omit functions that deal with 32-bit pointers and  
require everything to use 64-bit pointers.  You still need stuff like  
atoi that uses 32-bit values, though, and 64-bit-only does have a  
performance penalty.

Cheers,
Kyle Moffett

--
There is no way to make Linux robust with unreliable memory  
subsystems, sorry.  It would be like trying to make a human more  
robust with an unreliable O2 supply. Memory just has to work.
   -- Andi Kleen

Re: Pure 64 bootloaders

[Maciej W. Rozycki]

On Tue, 13 Sep 2005, Lennart Sorensen wrote:

> Of course mips is extra fun in having two 32bit formats and one 64bit
> format.

 The reverse -- two 64-bit formats and one 32-bit one.  And don't forget 
to multiply by two endiannesses. ;-)

  Maciej

Re: Pure 64 bootloaders

[Lennart Sorensen]

On Tue, Sep 13, 2005 at 06:21:23PM +0100, Maciej W. Rozycki wrote:
> On Tue, 13 Sep 2005, Lennart Sorensen wrote:
> 
> > Of course mips is extra fun in having two 32bit formats and one 64bit
> > format.
> 
>  The reverse -- two 64-bit formats and one 32-bit one.  And don't forget 
> to multiply by two endiannesses. ;-)

I thought it was 32bit old, 32bit new (for using 32bit pointers on a 64bit
cpu) and 64bit.  At least the names I have seen were 32o, 32n, 64.

Len Sorensen

Re: Pure 64 bootloaders

[Maciej W. Rozycki]

On Tue, 13 Sep 2005, Lennart Sorensen wrote:

> >  The reverse -- two 64-bit formats and one 32-bit one.  And don't forget 
> > to multiply by two endiannesses. ;-)
> 
> I thought it was 32bit old, 32bit new (for using 32bit pointers on a 64bit
> cpu) and 64bit.  At least the names I have seen were 32o, 32n, 64.

 Well, n32 requires a 64-bit CPU and uses 64-bit registers.  For C/C++ 
64-bit registers can be referred to with the "long long" types; I can't 
comment ABIs for other languages.  Pointers are indeed 32-bit.  Therefore 
for everything except ELF loaders the format can be considered 64-bit.

  Maciej

Re: Pure 64 bootloaders

[Harald Dunkel]

[-- Attachment #1: Type: text/plain, Size: 758 bytes --]

Jeff Garzik wrote:
> Andi Kleen wrote:
> 
>> Jim Gifford <maillist@jg555.com> writes:
>>
>>
>>> I have been working on a project to create a Pure 64 bit distro of
>>> linux, nothing 32 bit in the system. I can accomplish that with no
>>
>>
>>
>> Hopefully you're using /lib64 for that, otherwise your
>> packages will be incompatible to everybody else and not FHS compliant.
>> If you don't please don't submit any patches to hardcode this to
>> upstream packages.
> 
> 
> /lib64 is an awful scheme.  I'd avoid it.
> 

Indeed. It just helps to keep unclean 32bit applications
alive.

Maybe you would like to check Debian for amd64? The 32bit
stuff is purely optional (except for the boot loaders, AFAIK).

http://www.debian.org/ports/amd64/


Regards

Harri

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 256 bytes --]

RE: Pure 64 bootloaders

[Roger Heflin]

 

> -----Original Message-----
> From: linux-kernel-owner@vger.kernel.org 
> [mailto:linux-kernel-owner@vger.kernel.org] On Behalf Of Harald Dunkel
> Sent: Saturday, September 10, 2005 1:31 PM
> To: Jim Gifford
> Cc: Jeff Garzik; Andi Kleen; linux-kernel@vger.kernel.org
> Subject: Re: Pure 64 bootloaders
> 
> > 
> > 
> > /lib64 is an awful scheme.  I'd avoid it.
> > 
> 
> Indeed. It just helps to keep unclean 32bit applications alive.
> 

Reality is that it is difficulty to remove the older junk.

I guess I see 5 choices:

#1:
Use lib for whatever the standard os/arch size is.

Use lib32 for the non-standard size.

#2: 
Continue the current mess.

#3:
Use both lib32 and lib64 and maybe put a link from lib to the
default one, probably lib64.

#4:
Use both lib32 and lib64 and don't put a link.

#5:
Designate the bit size in the name of the lib, ie libc.so64 or
libc.so32 or something similar and put them all in the same
directory and let the lib loading code take care of finding the
correct size.

#5 would seem to be the most robust and simplest to administer,
and the most obvious, and the easiest to modify if something like
this was to happen again.

Who came up with lib64?  I thought I first saw it either on a
irix 6 machine or a early solaris 2.x machine.

                   Roger
> Maybe you would like to check Debian for amd64? The 32bit 
> stuff is purely optional (except for the boot loaders, AFAIK).
> 
> http://www.debian.org/ports/amd64/
> 
> 
> Regards
> 
> Harri
> 

Re: Pure 64 bootloaders

[Bastian Blank]

[-- Attachment #1: Type: text/plain, Size: 835 bytes --]

On Mon, Sep 12, 2005 at 09:50:20AM -0500, Roger Heflin wrote:
> I guess I see 5 choices:

6.

> #1:
> Use lib for whatever the standard os/arch size is.
> 
> Use lib32 for the non-standard size.

And what happens for machines with more than one 32 and one 64bit ABI?

> #2: 
> Continue the current mess.
> 
> #3:
> Use both lib32 and lib64 and maybe put a link from lib to the
> default one, probably lib64.
> 
> #4:
> Use both lib32 and lib64 and don't put a link.
> 
> #5:
> Designate the bit size in the name of the lib, ie libc.so64 or
> libc.so32 or something similar and put them all in the same
> directory and let the lib loading code take care of finding the
> correct size.

#6:
Use /lib/$arch-$os or similar and forgot about /lib/*.so.

Bastian

-- 
Beam me up, Scotty!  It ate my phaser!

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

Re: Pure 64 bootloaders

[Harald Dunkel]

[-- Attachment #1: Type: text/plain, Size: 990 bytes --]

Roger Heflin wrote:
> 
> I guess I see 5 choices:
> 
> #1:
> Use lib for whatever the standard os/arch size is.
> 
> Use lib32 for the non-standard size.
> 
> #2: 
> Continue the current mess.
> 
> #3:
> Use both lib32 and lib64 and maybe put a link from lib to the
> default one, probably lib64.
> 
> #4:
> Use both lib32 and lib64 and don't put a link.
> 
> #5:
> Designate the bit size in the name of the lib, ie libc.so64 or
> libc.so32 or something similar and put them all in the same
> directory and let the lib loading code take care of finding the
> correct size.
> 

I would say there is a sixth option, at least in theory: Add some
special symbols like 'LP64' or 'ILP32' to the symbol table, and add
a reference to one of these symbols to every *.o file. The linker
could distinguish between 32bit and 64bit implementation within the
same library. This would be similar to a symbol-versioned library.
But I am not sure whether this would be a reasonable option.


Regards

Harri

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 256 bytes --]

Re: Pure 64 bootloaders

[Stephen Frost]

[-- Attachment #1: Type: text/plain, Size: 912 bytes --]

* Andi Kleen (ak@suse.de) wrote:
> Jim Gifford <maillist@jg555.com> writes:
> > I have been working on a project to create a Pure 64 bit distro of
> > linux, nothing 32 bit in the system. I can accomplish that with no
> 
> Hopefully you're using /lib64 for that, otherwise your
> packages will be incompatible to everybody else and not 
> FHS compliant. If you don't please don't submit any 
> patches to hardcode this to upstream packages.

/lib64 sucks, as mentioned, and I thought FHS only required that the
linker be in /lib64.  Thus, the actual libraries could be pretty much
anywhere (as it should be, really).  Debian-amd64 uses a symlink from
/lib64 to /lib and provides the 64bit libraries and linker in /lib (but
when actually compiling does link binaries through /lib64 for FHS
compliance).

Hopefully /lib64, et al, will die and multiarch will happen soon.

	Thanks,

		Stephen

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: Pure 64 bootloaders

[Stefan Smietanowski]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi.

>>Jim Gifford <maillist@jg555.com> writes:
>>
>>>I have been working on a project to create a Pure 64 bit distro of
>>>linux, nothing 32 bit in the system. I can accomplish that with no
>>
>>Hopefully you're using /lib64 for that, otherwise your
>>packages will be incompatible to everybody else and not 
>>FHS compliant. If you don't please don't submit any 
>>patches to hardcode this to upstream packages.
> 
> 
> /lib64 sucks, as mentioned, and I thought FHS only required that the
> linker be in /lib64.  Thus, the actual libraries could be pretty much
> anywhere (as it should be, really).  Debian-amd64 uses a symlink from
> /lib64 to /lib and provides the 64bit libraries and linker in /lib (but
> when actually compiling does link binaries through /lib64 for FHS
> compliance).
> 
> Hopefully /lib64, et al, will die and multiarch will happen soon.

How exactly would multiarch support work then?

// Stefan
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (MingW32)

iD8DBQFDJDvcBrn2kJu9P78RAk9/AJ9KkdDxnqQmRSonntRZBqONlMH2pgCfQpH/
FDhtQSwqDrBzrQUb6/5YeOs=
=fEv6
-----END PGP SIGNATURE-----