[arch-dev-public] The need for /lib64 - testing please
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. Thanks, Allan
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.
On 01/07/11 18:10, Thomas Bächler wrote:
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.
Well, that was sort of what I was thinking as I had seen elsewhere other "pure 64" bit distros discussing only having that /lib64 symlink in a separate compatibility package (keeping / nice and clean...). So my thinking was to see how widespread the affected binary blobs were. Also, I have seen at least one binary blob using /lib/ld-linux-x86-64.so.2 instead of /lib32, I thought thinks might be shifting... Probably not given your comment regarding SuSE. Given I did not think about nvidia-settings and its widespread use, I agree that this whole thing would be overkill. Allan
participants (2)
-
Allan McRae
-
Thomas Bächler