Re: 64-bit packaging details

[Peter <pk@q-leap.com>]

Arnd Bergmann writes:
 > On Friday 30 May 2003 23:06, Juergen Kreileder wrote:
 > > Arnd Bergmann <arnd@arndb.de> writes:
 > > > The /lib64 name is mandated by the ELF ABI, although there
 > > > are a few exceptions like '/usr/lib/gcc-lib/i386-linux/3.3/64/'.
 > >
 > > Shouldn't that be '/usr/lib64/gcc-lib/x86_64-linux/3.3/32'?
 > 
 > It depends. Currently, the compiler is built for i386, so
 > '/usr/lib/gcc-lib/i386-linux/3.3/64/' is correct. When we start building
 > the compiler itself as a 64 bit binary, we'll have to decide
 > on something different.
 > 
 > AFAIK, Red Hat Linux uses '/usr/lib/gcc-lib/x86_64-linux/3.3{,/32}', which
 > makes sense: .../gcc-lib/... has its own subdirs for different ABIs (i.e.
 > not only limited to 32 and 64 bit), so it should not be below the path
 > for a specific ABI but below the most generic path. The same is true
 > for e.g. /usr/lib/X11/... and /usr/lib/perl/... .
 > 
 > Note that gcc uses a different logic for finding its own libraries (libstdc++,
 > libgcc, ...) vs. finding system libraries on biarch systems.
 > 

Does that mean there is not going to be a /usr/X11R6/lib64, or a
/usr/lib64 directory?  Or, for example, where is is Python going to
put its libraries under lib-dynload, or lib64-dynload?
Do I understand it right, that the lib64-directories are only needed
for a 32/64 bit mixed system, and if Python, for example, is ported to
amd64, then there probably is only going to be this Python, and thus
no need for a lib64-dynload?  More general, if we have an amd64 only
system then even the /lib64 directory is obsolete?

little bit confused.

	   Peter

-- 
Peter Kruse <pk@q-leap.com>
Q-Leap Networks GmbH
phone: +497071-703171, mobile: +49172-6340044