On Fri, Jul 1, 2011 at 3:10 PM, Thomas Bächler <thomas@xxxxxxxxxxxxx> wrote: > 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). Just FTR, it most likely comes from http://www.pathname.com/fhs/pub/fhs-2.3.html#LIB64
