classification
Title: Default Python 3.7 install broken on openSUSE Leap 42.3: $PYTHONHOME/lib64/python3.7/lib-dynload/ not linked to $PYTHONHOME/lib/python3.7/lib-dynload/
Type: behavior Stage: resolved
Components: Installation Versions: Python 3.7
process
Status: closed Resolution: duplicate
Dependencies: Superseder: Add sys.platlibdir and configure --with-platlibdir to use /usr/lib64 on Fedora and SuSE
View: 1294959
Assigned To: Nosy List: cooperlees, terry.reedy, tkandell, vstinner
Priority: normal Keywords:

Created on 2018-07-06 00:53 by tkandell, last changed 2020-03-11 10:01 by vstinner. This issue is now closed.

Files
File name Uploaded Description Edit
configure.log tkandell, 2018-07-07 08:28 Output of ./configure for Python 3.7.0 on linux 4.4.114-42-default openSUSE 42.3
make.log tkandell, 2018-07-07 08:47 The output of make with no parameters (after make clean)
Messages (13)
msg321145 - (view) Author: Ted Kandell (tkandell) * Date: 2018-07-06 00:53
The default Python 3.7 install (./configure with no parameters) does not work (at least) on openSUSE Leap 42.3. 

Python3 gives a ModuleNotFoundError: No module named 'readline'
 error, and pip3 has a ModuleNotFoundError: No module named '_socket' error, because the site libraries cannot be found.

The fix is to manually:
sudo ln -s /usr/local/lib64/python3.7/lib-dynload/ /usr/local/lib/python3.7/lib-dynload

The same problem should also be present with a PYTHONHOME other than the default /usr/local .

I suspect this is a more widespread problem than just openSUSE Leap 42.3, and may exist in other distros as well.

The fix should be for make install to automatically create the symbolic link for the  $PYTHONHOME/lib64/python3.7/lib-dynload directory in $PYTHONHOME/lib/python3.7/ .
msg321199 - (view) Author: Terry J. Reedy (terry.reedy) * (Python committer) Date: 2018-07-07 02:19
A crash, for the tracker, is failed execution without a Python exception and trackback.

Debian, Fedora, Gentoo, RHEL, and Ubuntu (AMD64) buildbots are currently green.  We don't have one for SUSE, open or other wise.

If you have not yet reported the issue to openSUSE, I would do so in case this is something they should deal with.

Victor, do you have anything to add?
msg321200 - (view) Author: Ted Kandell (tkandell) * Date: 2018-07-07 02:46
This isn't for the OpenSUSE official build itself, just compiling and installing from source on OpenSUSE 42.3. Without the symlink, and also with a wrong PYTHONHOME, pip coredumps.
msg321204 - (view) Author: Terry J. Reedy (terry.reedy) * (Python committer) Date: 2018-07-07 05:21
Did you get the source from openSUSE or from python.org?
msg321205 - (view) Author: STINNER Victor (vstinner) * (Python committer) Date: 2018-07-07 07:09
Can we please recommpile Python from scratch and attach the output of make? Example:

./configure
make 2>&1 | tee log

And attach log to this ticket.
msg321206 - (view) Author: STINNER Victor (vstinner) * (Python committer) Date: 2018-07-07 07:10
For readline, you probably have to install a dependency like: libreadline-dev.
msg321207 - (view) Author: STINNER Victor (vstinner) * (Python committer) Date: 2018-07-07 07:13
> Debian, Fedora, Gentoo, RHEL, and Ubuntu (AMD64) buildbots are currently
green.  We don't have one for SUSE, open or other wise.

We have SLES buildbots, that's OpenSUSE no?
msg321208 - (view) Author: Ted Kandell (tkandell) * Date: 2018-07-07 08:21
I got the source directly from www.python.org
msg321209 - (view) Author: Ted Kandell (tkandell) * Date: 2018-07-07 08:28
./configure output
default, no parameters
msg321211 - (view) Author: Ted Kandell (tkandell) * Date: 2018-07-07 08:47
The output of make after a make clean is attached.

For readline, on openSUSE 42.3 you have to install ncurses-devel, not libreadline-dev. The instructions aren't clear about this either, or the fact that an ncurses or readline development library has to be installed separately. However, this didn't cause the "readline" problem, since the shared libraries were in /usr/local/lib64 instead of /usr/local/lib, and so they couldn't be found in any case.
msg345363 - (view) Author: Cooper Lees (cooperlees) * Date: 2019-06-12 14:13
I also have the same problem with _socket that was Fixed on the latest version of CentOS 7 building with gcc 4.8.5.

Adding:
sudo ln -s /usr/local/lib64/python3.7/lib-dynload/ /usr/local/lib/python3.7/lib-dynload

Allowed the .so to be found and the import to work.
msg363898 - (view) Author: STINNER Victor (vstinner) * (Python committer) Date: 2020-03-11 09:50
bpo-1294959 has been fixed by commit 8510f430781118d9b603c3a2f06945d6ebc5fe42, but this issue is about "./configure with no parameters".

This issue seems to be about OpenSuSE downstream patches: "just compiling and installing from source on OpenSUSE 42.3."

I found multiple similar old issues.

bpo-15631: "Python 3.3/3.4 installation issue on OpenSUSE lib/lib64 folders", "error: ImportError: No module named 'atexit'". The reporter used downstream patch: "I applied the OpenSUSE patch".

=> closed as a duplicate of bpo-1294959

* bpo-18092: "Python 2.7.5 installation broken on OpenSuse 12.2", error: "ImportError: No module named _collections". The reporter never explained how Python was configured: "Please provide exactly what ./configure options you used to build Python and any "make install" options."

=> closed as a duplicate of bpo-1294959

* bpo-30633: "Python 3.6.1 installation issues on OpenSuse 42.1: ModuleNotFoundError: No module named 'encodings'", error: "Fatal Python error: Py_Initialize: Unable to get the locale encoding". Same reporter name than bpo-18092 "Andreas Jung", but different bugs.python.org login name ("zopyx" vs "Andreas.Jung". The reporter says that he used "the standard ./configure --prefix=... --enable-optimizations" but not if he applied any OpenSuSE downstream patch.

=> closed as out of date in 2019 after 2 years of inactivity
msg363899 - (view) Author: STINNER Victor (vstinner) * (Python committer) Date: 2020-03-11 10:01
This issuse is now 2 years old and it doesn't have a clear description. It started with "just compiling and installing from source on OpenSUSE 42.3", then switched to "I got the source directly from www.python.org" to finish with "I also have the same problem (...) on the latest version of CentOS 7".

I close the issue.

If someone wants to reopen the issue, please clearly explains:

* how you get Python
* did you apply any patch on it
* how did you configure Python? (configure command)
* how did you built Python?
* how did you install Python?
* how do you run Python?
* what is your operating system?
* what is your locale (LC_ALL, LC_CTYPE and LANG environment variable)?
* do you have any environment variable with a name starting with PYTHON?

So far, we only got unclear bug reports with partial information and we could only guess what the reporter did.

Since this issue started with OpenSuSE downstream patches, I mark also this issue as a duplicate of bpo-1294959.
History
Date User Action Args
2020-03-11 10:01:32vstinnersetstatus: open -> closed
superseder: Add sys.platlibdir and configure --with-platlibdir to use /usr/lib64 on Fedora and SuSE
messages: + msg363899

resolution: duplicate
stage: resolved
2020-03-11 09:50:57vstinnersetmessages: + msg363898
2019-06-12 14:13:23cooperleessetnosy: + cooperlees
messages: + msg345363
2018-07-07 08:47:26tkandellsetfiles: + make.log

messages: + msg321211
2018-07-07 08:28:49tkandellsetfiles: + configure.log

messages: + msg321209
2018-07-07 08:21:42tkandellsetmessages: + msg321208
2018-07-07 07:13:24vstinnersetmessages: + msg321207
2018-07-07 07:10:43vstinnersetmessages: + msg321206
2018-07-07 07:09:53vstinnersetmessages: + msg321205
2018-07-07 05:21:03terry.reedysetmessages: + msg321204
2018-07-07 02:46:15tkandellsetmessages: + msg321200
2018-07-07 02:19:23terry.reedysetnosy: + vstinner, terry.reedy
type: crash -> behavior
messages: + msg321199
2018-07-06 00:53:40tkandellcreate