What's the difference between /usr/lib/python and /usr/lib64/python?
I was using ubuntu.
I found that many Python libraries installed went in both /usr/lib/python and /usr/lib64/python.
When I print a module object, the module path showed that the module lived in /usr/lib/python.
Why do we need the /usr/lib64/python directory then?
What's the difference between these two directories?
BTW
Some package management script and egg-info that lived in both directories are actually links to packages in /usr/share.
Most Python modules are just links, but the so files are not.
Debian (and probably it's derivatives, most notably ubuntu) uses /usr/lib for both architectures. /usr/lib64 is provided as a symlink to /usr/lib for compatibility reasons. Some newer applications might be looking in /usr/lib64 for libraries, while some legacy code might be using /usr/lib. Other distributions can provide multi-architecture support, having 32 bit and 64 bit libraries installed on the same machine, which would then be placed in /usr/lib and /usr/lib64 accordingly. An example of this would be Arch Linux, as described here.
Some python libraries are platform independent anyway (.py code), so it makes sense to create a single package for both architecture to minimize maintenance effort. This package would then install itself in both lib and lib64, or, as you pointed out already, in one single directory that is symlinked to from both lib and lib64.
The 64-bit version of the libraries?
What version of Python are you running? If you are running the 32-bit version, then you probably won't need those files.
7 Comments
@Satoru.Logic So it is quite possible that you got both the 32 bit version of Python and 64 bit installed.
@Satoru.Logic And since I haven't installed any 64-bit software, my /usr/lib64 directory is empty but for a directory called libfakeroot.
OK, if there are separate .so files, you can check whether the lib and lib64 ones actually are 32-bit and 64-bit libs (I believe the "file" command tells you that, which is simpler than using elftools, etc.). If so, this answer is 99% correct. If you never want to run 64-bit Python, you can delete them.
Oops… Actually, there's one potential problem. If you want to build and install new modules that depend on existing ones, they may see "aha, he's got both 32- and 64-bit, I'd better build both ways", and then the build may fail because the 64-bit build depends on a .so that's no longer there… More importantly, do you really need to recover the space? The largest Python lib I have on any machine is 27MB, and that's Mac fat binaries (double normal size), with tons of extra stuff installed. I can't remember how long ago 27MB was a noticeable dent on my disk space, even on my phone…
Explore related questions
See similar questions with these tags.