[Python-bugs-list] [ python-Bugs-425007 ] Python 2.1 installs shared libs with mode 0700
noreply@sourceforge.net
noreply@sourceforge.net
Mon, 21 May 2001 13:15:02 -0700
Bugs item #425007, was updated on 2001-05-17 16:28
You can respond by visiting:
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=425007&group_id=5470
>Category: Distutils
Group: None
Status: Open
Resolution: None
>Priority: 6
Submitted By: Nobody/Anonymous (nobody)
Assigned to: A.M. Kuchling (akuchling)
Summary: Python 2.1 installs shared libs with mode 0700
Initial Comment:
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.
----------------------------------------------------------------------
>Comment By: A.M. Kuchling (akuchling)
Date: 2001-05-21 13:15
Message:
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.
----------------------------------------------------------------------
Comment By: Guido van Rossum (gvanrossum)
Date: 2001-05-21 12:32
Message:
Logged In: YES
user_id=6380
Assigning this to Andrew -- clearly the setup.py script (or
distutils) needs to be fixed to fix this.
----------------------------------------------------------------------
Comment By: Guido van Rossum (gvanrossum)
Date: 2001-05-21 12:24
Message:
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.
----------------------------------------------------------------------
Comment By: Greg Copeland (oracle)
Date: 2001-05-21 08:13
Message:
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.
----------------------------------------------------------------------
Comment By: Guido van Rossum (gvanrossum)
Date: 2001-05-20 10:35
Message:
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.
----------------------------------------------------------------------
Comment By: Kurt B. Kaiser (kbk)
Date: 2001-05-19 17:16
Message:
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?
----------------------------------------------------------------------
You can respond by visiting:
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=425007&group_id=5470