[arch-dev-public] The need for /lib64 - testing please

[Thomas Bächler]

Am 01.07.2011 06:48, schrieb Allan McRae:
> Hi all,
> 
> I was looking at the /lib64 folder and wondering what it is really
> needed for...  It just seems clutter to me on a pure x86_64 system (or
> even with a multilib in lib32 folders like we have). As far as I can
> tell, most things are perfectly fine without that folder and its two
> symlinks.
> 
> I would like some help testing removing this so I can get an idea of
> what issues people run into.  There is bound to be some software that
> makes assumptions about /lib64 in its installation and I would like to
> know (a) how widespread that issue is and (b) how hard it is to work
> around.
> 
> If you want to try it out, just remove the /lib64 folder (after making
> sure it only has symlinks to ld-2.13.so and ld-linux-x86-64.so.2 in it.
> Run your system as usual for a while and report any issues you come across.

First of all, /lib64/ld-2.14.so is unnecessary, only
/lib/ld-linux-x86-64.so must exist.

The problem is quite simple: The ELF binary hardcodes the path to the
interpreter (which is the linker). Binaries that were compiled for other
distributions or generic binaries distributed by third parties will have
the path "/lib64/ld-linux-x86-64.so.2" hardcoded as their interpreter -
I don't know where this convention comes from and why they didn't choose
/lib (choosing /lib would be no problem, as the file names for the 32
and 64 bit linkers differ, the former is ld-linux.so.2). At least SuSE
doesn't even have /lib/ld-linux-x86-64.so.2, so binaries compiled on
Arch will not work on SuSE unless you create that symlink yourself.

Problematic binaries include all utilities that come with
nvidia-settings, the entire virtualbox binary distribution, or any other
binary-only 64 bit application. By removing this symlink, we will
completely break compatibility with third-party binaries. This will
never change, so I don't see the point in your experiment.

We could have a special "x86-64-binary-compat" package including only
this symlink, and have binary packages depend on it. That seems like
overkill though.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 262 bytes
Desc: OpenPGP digital signature
URL: <http://mailman.archlinux.org/pipermail/arch-dev-public/attachments/20110701/2eba4db9/attachment.asc>