[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: 64-bit packaging details

Hash: SHA1

On Saturday 31 May 2003 10:54, Peter wrote:
> Arnd Bergmann writes:
>  >
>  > 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?
Sorry, I was confused about the X11R6 bit, which is /usr/lib/X11/lib64
on some other distributions. The FHS path is /usr/X11R6/lib64, with
a symlink from /usr/lib64/X11.

> 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? 
The lib-dynload is specific to one interpreter and you can not easily
install both the 32 and 64 bit package of python-2.2, so there is
no need to call the directory lib64-dynload. It can be done for symmetry
reasons, but this question can be left to the python maintainer.

> More general, if we have an amd64 only system then even the /lib64 
> directory is obsolete?

No, because the path has to be known at some place, e.g. every 
dynamic binary contains a reference to /lib64/ld-linux-x86-64.so.2.
The package behavior should not depend on the presence of 32 bit
libraries in {,/usr}/lib, so the {,/usr}/lib64 paths will never be obsolete.

	Arnd <><
Version: GnuPG v1.2.1 (GNU/Linux)


Reply to: