Issue425007
This issue tracker has been migrated to GitHub,
and is currently read-only.
For more information,
see the GitHub FAQs in the Python's Developer Guide.
Created on 2001-05-17 23:28 by anonymous, last changed 2022-04-10 16:04 by admin. This issue is now closed.
Messages (12) | |||
---|---|---|---|
msg4788 - (view) | Author: Nobody/Anonymous (nobody) | Date: 2001-05-17 23:28 | |
I have gone back and tried Python 1.6 and 2.0. Both work fine. When I install Python 2.1, everything is broken. The problem is that when a module is a shared library (.so), python refuses to load the module. Example: import os import sys import SocketServer Traceback (most recent call last): File "<stdin>", line 1, in ? File "/usr/lib/python2.1/SocketServer.py", line 126, in ? import socket File "/usr/lib/python2.1/socket.py", line 41, in ? from _socket import * ImportError: No module named _socket Now, do a "locate _socket.so" and I get: /usr/lib/python2.1/site-packages/_socket.so /usr/lib/python2.1/lib-dynload/_socket.so Clearly they are there, it's just that Python refuses to load them. I made Python 2.1 from source as fetched from the 2.1 tar ball. It makes cleanly. During the installation, I see some items that I believe to be minor that popup, but don't currectly expect that they are the problem. I have tried many times using different configure options to get this to work, deleting the previous installation each time. I've even tried installing in different locations. As is, Python 2.1 is completely broken for me. Surely I'm not the only one having this problem, especially since 1.5, 1.6, and 2.0 all work correctly. Any help would be great. BTW, doing a "print sys.path" gives me: ['', '/usr/lib/python2.1', '/usr/lib/python2.1/plat-linux2', '/usr/lib/python2.1/lib-tk', '/usr/lib/python2.1/lib-dynload', '/usr/lib/python2.1/site-packages'] As you can see, lib-dynload is in the path, so I'm not really sure what's going on. |
|||
msg4789 - (view) | Author: Kurt B. Kaiser (kbk) * | Date: 2001-05-20 00:16 | |
Logged In: YES user_id=149084 Well, import SocketServer works ok for me with Python built both from the 2.1 tar file and the 2.2a0 CVS tree. I'm running Linux 2.2.5 (RH 6.2) on Pentium. Did you make clean after changing the configure options? It is not normal to have _socket.so in .../site-packages; it should be only in .../lib-dynload. Default installation has only the README file in site-packages. Your sys.path looks normal, except that Python default installs at /usr/local/[bin/lib]. I tried a build targeted at /usr/[bin/lib] and it was ok. You could try make clobber, but it's almost as fast to start over. Try a vanilla installation: 1. delete your install tree @ /usr/local/lib/python2.1 (and/or /usr/lib) 2. delete your source tree from wherever you unpacked the tar file. 3. untar again, cd to source directory it created 4. without changing any files, and no configure options, run ./configure, then make, then make install If that doesn't help, what Linux are you running, on what box, and where did you get your 2.1 tar file? |
|||
msg4790 - (view) | Author: Guido van Rossum (gvanrossum) * | Date: 2001-05-20 17:35 | |
Logged In: YES user_id=6380 Clearly it's something you have done to yourself. :-) The question is how to find out what. Try "python -v" or even "python -vv" and see what it prints when you try to import _socket. This should give you some clues (it shows where it searches for modules during import). As kbk says, that other _socket.so is mysterious. |
|||
msg4791 - (view) | Author: Greg Copeland (oracle) | Date: 2001-05-21 15:13 | |
Logged In: YES user_id=40173 The problem is that the installation is partially broken. It didn't install the shared libraries with proper permissions. When Python installed the shared libs, it installed the libs as root.root having 0700 permissions. When I tried to execute it as a normal user, obviously, it fails to load the shared lib. Python then, incorrectly reports that the shared lib can not be found. Of course, the correct solution is for Python to accurately report the problem and to have the installation always install the libraries with correct ownership and permission. I don't think I'm asking for too much here. Seems pretty reasonable to me. Anyone stating that I did not install correctly is woefully incorrect. Simply put, the installation is not 100%. As for some of the libraries existing twice. Well, simply put, the installation is not 100%. At any rate, I think it's safe to close this bug but we might want to add it to the faq-o-matic somewhere or some such thing. |
|||
msg4792 - (view) | Author: Guido van Rossum (gvanrossum) * | Date: 2001-05-21 19:24 | |
Logged In: YES user_id=6380 I didn't mean to imply that you did something incorrectly. I just meant that there was some interaction between your system and Python that didn't work out the way it was supposed to be. Since Python installs correctly on most systems, I was implying that there's something unusual in your system that the Python install procedure doesn't anticipate. The mode 0700 for the shared libraries is a big hint at what was wrong (and if you had done an ls -l of the file when first reporting this we would have figured out the problem much quicker). Is perhaps the umask of the user who built (not installed) the files set to 077? In that case, the cause is that the "make install" by root doesn't change the file modes to something more reasonable (I've confirmed that this indeed happens). I'll look into whether this can be fixed. I'm changing the subject line of this bug report to reflect more accurately that the problem is with the file modes of shared libs. I still believe that the _socket.so in site-packages could not have been placed there by the normal Python install procedure. |
|||
msg4793 - (view) | Author: Guido van Rossum (gvanrossum) * | Date: 2001-05-21 19:32 | |
Logged In: YES user_id=6380 Assigning this to Andrew -- clearly the setup.py script (or distutils) needs to be fixed to fix this. |
|||
msg4794 - (view) | Author: A.M. Kuchling (akuchling) * | Date: 2001-05-21 20:15 | |
Logged In: YES user_id=11375 Reclassifying as a Distutils bug. The install_lib subcommand simply copies the contents of the BUILD/ tree. It needs to pointedly ignore the umask and set the proper permissions on the installed files. |
|||
msg4795 - (view) | Author: Kurt B. Kaiser (kbk) * | Date: 2001-05-22 06:24 | |
Logged In: YES user_id=149084 INSTALLATION: Confirm. Built with umask 077, group and others have no permissions in source tree. (Note that if I su to install, the 077 follows! ok, install with umask of 022, normal for root.). Everything in installation looks ok except for lib-dynload, which has 700 permissions on files. No _socket.so in site-packages. REINSTALLATION: I suspect there is more to this than distutils...Redo the build with umask 022. Then chmod the whole previously installed tree to 700 and if you then repeat the install on top of it you find that while the .py files have been correctly copied by /usr/bin/install with 644, the .pyc and .pyo are still 700 though recompiled. This also happens in 1.5.2. The lib-dynload files are 755. This is with a umask of 022 for both the build user and root. Finally, delete a few files from lib-dynload, chmod the rest to 700, and make install again! The deleted files are restored at 755, the rest stay at 700. In general, messed up permissions are not fixed by a re-install. It would seem desirable that re-installing should result in exactly the same install tree as the initial install, including permissions, except that any non-distribution files (e.g. "site-packages") added by the user would be unaffected. If the user had modified some distribution .py files they would be reverted by the re-install, which does seem to be the case. A broken installation could be repaired by re-installing. Would that be a reasonable policy? Or is it too difficult to fix up all the permissions? A compromise might be to delete the .pyo .pyc before compiling, and explicitly chmod all the lib-dynload files during install. |
|||
msg4796 - (view) | Author: Michael Hudson (mwh) | Date: 2002-01-16 14:28 | |
Logged In: YES user_id=6656 I'll do something about this at some point. Using copy_tree to install shared libraries is gross. |
|||
msg4797 - (view) | Author: Nobody/Anonymous (nobody) | Date: 2002-05-20 23:47 | |
Logged In: NO Found a similar problem on Mac OS X's command line installation of Python 2.2.1. Darwin kernel 5.4 OS X 10.1.4. Apple's gcc 2.95.2. Built as regular user, umask 077. Ran make install as root, umask 022. All files in /usr/local/lib/python-2.2/lib-dynload were mode 711, which is not sufficient for python to load them. Same error as this problem "ImportError: No module named time". Error is clearer when viewed as: >>> help() help> modules time [Traceback redacted for brevity] IOError: [Errno 13] Permission denied: '/usr/local/lib/python2.2/lib-dynload/MacOS.so' Suggest you add a comment on this to the README's Troubleshooting section. |
|||
msg4798 - (view) | Author: Michael Hudson (mwh) | Date: 2002-11-08 14:20 | |
Logged In: YES user_id=6656 patch #629278 promises to help with this. |
|||
msg4799 - (view) | Author: Michael Hudson (mwh) | Date: 2002-12-17 16:48 | |
Logged In: YES user_id=6656 Fixed in patch 629278 |
History | |||
---|---|---|---|
Date | User | Action | Args |
2022-04-10 16:04:04 | admin | set | github: 34517 |
2001-05-17 23:28:20 | anonymous | create |