4

I am currently playing around with cmake a bit and in the process I discovered a few things I don't understand mostly concerning python symbolic links in usr/bin directory:

  1. In my usr/bin directory there exist symbolic links with almost the name of the python executables they point to. It seems to be a while since they were created and I want to know if there could be a reason why this is necessary or if something went wrong at some point and I should delete these symbolic links.

  2. What are the symbolic links pointing to x86_64-linux-gnu-python<x.x>-config* for?

  3. This is more a python specific question: What is the difference between python3.5 and python3.5m?

My usr/bin looks like this:

lrwxrwxrwx  1 root    root           9 Okt 18  2016 python -> python2.7*
lrwxrwxrwx  1 root    root           9 Okt 18  2016 python2 -> python2.7*
-rwxr-xr-x  1 root    root     3546104 Nov 19 10:35 python2.7*
lrwxrwxrwx  1 root    root          33 Nov 19 10:35 python2.7-config -> x86_64-linux-gnu-python2.7-config*
lrwxrwxrwx  1 root    root          16 Dez 10  2015 python2-config -> python2.7-config*
lrwxrwxrwx  1 root    root           9 Okt 18  2016 python3 -> python3.5*
-rwxr-xr-x  2 root    root     4460336 Nov 17 20:23 python3.5*
lrwxrwxrwx  1 root    root          33 Nov 17 20:23 python3.5-config -> x86_64-linux-gnu-python3.5-config*
-rwxr-xr-x  2 root    root     4460336 Nov 17 20:23 python3.5m*
lrwxrwxrwx  1 root    root          34 Nov 17 20:23 python3.5m-config -> x86_64-linux-gnu-python3.5m-config*
lrwxrwxrwx  1 root    root          16 Mär 23  2016 python3-config -> python3.5-config*
lrwxrwxrwx  1 root    root          10 Okt 18  2016 python3m -> python3.5m*
lrwxrwxrwx  1 root    root          17 Mär 23  2016 python3m-config -> python3.5m-config*
lrwxrwxrwx  1 root    root          16 Dez 10  2015 python-config -> python2.7-config*
2

About the python3.5m, it is the default python.

As it is in the mailing list: https://mail.python.org/pipermail/python-list/2016-June/710983.html

The "m" suffix means that Python is configured "--with-pymalloc", i.e. using specialized mallocs, including the small-object allocator. This is the default configuration. You may also see a "dm" suffix for a build that's configured "--with-pydebug" and "--with-pymalloc".

libpython3.5.so and libpython3.5m.so may actually link to the same shared library:

$ readlink libpython3.5.so
../../x86_64-linux-gnu/libpython3.5m.so.1

$ readlink libpython3.5m.so
../../x86_64-linux-gnu/libpython3.5m.so.1

About the links, they appear normal, it is just moving names and locations around to privide a standard environment for the user; from the links it can be seen the default python is 2.7 and python 3 is linking to 3.5

  • So the symbolic links are mainly created to make it easier on the user? Also if python3.5m is the default, why doesn't python3.5 link to python3.5m? – uitty400 May 3 '17 at 12:49
  • @uitty400 python3.5 does "not point" to python3.5m because it is most probably a hard link, and not a symbolic link. Compare their size and data; the two names point to the same file. – Rui F Ribeiro May 3 '17 at 12:50
  • 4
    @uitty400 Your listing shows that python3.5m and python3.5 both have 2 hard links--most likely to the same disk file. List using ls -il to see if they have the same inode number. The second column of the listing in your display is the number of hard links. You can see that all other file entries have 1 hard link. – user4556274 May 3 '17 at 12:52

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.