All - Today I ran up against an issue with Python's "make altinstall" option on OpenSuse, which is that using the documented configure; make; make altinstall results in binaries that will not run without some corrective linking post-install. The issue anecdotally appears to be limited to Suse. BACKGROUND: 1. Building python from source (configure; make) completes as expected. 2. Python provides an alternative install makefile target "altinstall" which is designed to install Python in /usr/local in such a way that it does not interfere with other (existing) Python installations anywhere on the system. This install target seems to work as well. 3. However, trying to run the binaries installed by make altinstall results in failure messages:
/usr/local/bin/python3.8 Could not find platform dependent libraries <exec_prefix> Consider setting $PYTHONHOME to <prefix>[:<exec_prefix>] Python 3.8.1 (default, Jan 21 2020, 17:09:11) [GCC 7.4.1 20190905 [gcc-7-branch revision 275407]] on linux Type "help", "copyright", "credits" or "license" for more information. Traceback (most recent call last): File "/etc/pythonstart", line 7, in <module> import readline ModuleNotFoundError: No module named 'readline'
/usr/local/bin/pip3.8 Could not find platform dependent libraries <exec_prefix> Consider setting $PYTHONHOME to <prefix>[:<exec_prefix>] Traceback (most recent call last): File "/usr/local/bin/pip3.8", line 6, in <module> from pip._internal import main File "/usr/local/lib/python3.8/site-packages/pip/_internal/__init__.py", line 19, in <module> from pip._vendor.urllib3.exceptions import DependencyWarning File "/usr/local/lib/python3.8/site-packages/pip/_vendor/urllib3/__init__.py", line 7, in <module> from .connectionpool import ( File "/usr/local/lib/python3.8/site-packages/pip/_vendor/urllib3/connectionpool.py", line 7, in <module> from socket import error as SocketError, timeout as SocketTimeout File "/usr/local/lib/python3.8/socket.py", line 49, in <module> import _socket ModuleNotFoundError: No module named '_socket'
4. Obvious things like ldconfig have no effect. However, there is an ln -s command that can resolve this issue: ln -s /usr/local/lib64/python3.8/lib-dynload /usr/local/lib/python3.8/lib-dynload After running that command, the above two binaries at least seem to run without error. In the process of Googling to find that solution, I discovered that this problem is limited to (or has only been reported on) OpenSuse. I have duplicated it on clean installs of 42.3, 15.0 and 15.1 so far. I haven't tried SLES or TW, but I'm guessing if we have the problem, they probably do too. OBSERVATIONS: 1. It seems to me that this works for all other distros except ours, so maybe this is an OpenSuse problem? -but- 2. It seems to me that Python should detect whatever is causing this and add that command to its make altinstall target so that we don't have to go through this... so maybe Python should fix this? -and- 3. Make is building 64 bit binaries here, so by convention we should be looking in /usr/local/lib64 anyway, so why are we looking in /usr/local/lib for libraries instead? I have no idea whose problem that might be. It seems to be a PYTHONPATH variable being set in the makefile, but,a again, if that's the problem, why does it seem to work (s/work/not be reported/) for other distros? QUESTION: Whose problem is this? Should I report it to Python? I can't imagine they'd care, wouldn't they just blame OpenSuse? Should I bug report it to OpenSuse? Just live with it? Or am I missing something obvious that I should have known all along? This is a problem that's clearly existed for a while, others have run into it with previous versions of Python and OpenSuse (cf. https://stackoverflow.com/questions/51201459/python-3-7-install-not-working-... et al) - it still exists with Python 3.8.1 on OpenSuse 15.1... and everyone says "Put in the symlinks and be content." But it seems to me that - someone - should be made aware of this with an eye to generating a more robust fix than Google? So what is the "right thing" to do here? P.S. I am aware that OBS has experimental installable packages. But for me, that's off point here. What I am trying to do here is not so much get a fix for myself - I can symlink just fine - but rather trying to get the underlying *cause* of this issue fixed at the core, so that future OpenSuse users don't have to deal with it. Trying to "do the right thing", if possible, for the OpenSuse community. Thank you all for any clue bats you'd be willing to smash over my head. Glen -- To unsubscribe, e-mail: opensuse-support+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-support+owner@opensuse.org