[issue26971] python v3.5.1: sys.paths not respecting DESTDIRS and DESTSHARED

[Xavier de Gaye]

Change by Xavier de Gaye :


--
nosy:  -xdegaye

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue26971] python v3.5.1: sys.paths not respecting DESTDIRS and DESTSHARED

[Xavier de Gaye]

Xavier de Gaye added the comment:

The problem is that Makefile and Modules/getpath.c are not consistent:
* Makefile uses $(LIBDIR)/python$(VERSION)/lib-dynload as the location of the 
installed shared libraries and in this issue, it happens that LIBDIR is not 
${exec_prefix}/lib but is ${exec_prefix}/lib64 instead.
* Py_GetPath() in Modules/getpath.c uses the concatenation of EXEC_PREFIX with 
"lib/python", VERSION and "lib-dynload" to construct the corresponding sys.path 
entry when falling back to using the EXEC_PREFIX preprocessor variable.

Another problem may be that with this issue, Py_GetPath() constructs the string 
"/some/path/to/install/lib/lib-dynload" missing entirely the python$(VERSION) 
component part (as shown by sys.path in the interpreter).

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue26971] python v3.5.1: sys.paths not respecting DESTDIRS and DESTSHARED

[Xavier de Gaye]

Xavier de Gaye added the comment:

The problem can be reproduced as follows:

Run the following commands to install python with a site configuration file 
that installs the libraries to lib64:

  export INSTALL_DIR=/some/path/to/install
  mkdir -p $INSTALL_DIR/share
  echo "test \"\$libdir\" = '\${exec_prefix}/lib' && 
libdir='\${exec_prefix}/lib64'" > $INSTALL_DIR/share/config.site
  ./configure --prefix=$INSTALL_DIR && make install

Check that the libraries have been installed to lib64 and that python fails to 
find them:

$ find $INSTALL_DIR -name lib-dynload
/some/path/to/install/lib64/python3.6/lib-dynload

$ $INSTALL_DIR/bin/python3 -E
Could not find platform dependent libraries 
Consider setting $PYTHONHOME to [:]
Python 3.6.0a4+ (default:98a57845c8cc, Sep  9 2016, 15:34:27) 
[GCC 6.1.1 20160707] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import base64
Traceback (most recent call last):
  File "", line 1, in 
  File "/some/path/to/install/lib/python3.6/base64.py", line 10, in 
import struct
  File "/some/path/to/install/lib/python3.6/struct.py", line 13, in 
from _struct import *
ModuleNotFoundError: No module named '_struct'
>>>

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue26971] python v3.5.1: sys.paths not respecting DESTDIRS and DESTSHARED

[Xavier de Gaye]

Xavier de Gaye added the comment:

> Sorry that I haven't answered for a long time. I would like to get an email 
> notification but I don't know whether/how I can enable it.

You should get an email upon each message posted to this issue. The email is 
sent to the address you have registered with as "jojo".


So your config.log confirms that the configure script does use 
${exec_prefix}/lib64.
Your system may be configured with a configure system-wide initialization file 
[1]. In that case, configure will print a line starting with:
"loading site script ..."
and showing the path to the config.site file that is being loaded. As described 
at the end of [1], this is where libdir may be set to '${exec_prefix}/lib64'.

[1] 
https://www.gnu.org/software/autoconf/manual/autoconf-2.68/html_node/Site-Defaults.html

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue26971] python v3.5.1: sys.paths not respecting DESTDIRS and DESTSHARED

[Johannes S.]

Johannes S. added the comment:

Sorry that I haven't answered for a long time. I would like to get an email 
notification but I don't know whether/how I can enable it.

On "my instance of Linux SuSE", the lines are locking like this:

CONFIG_ARGS=' '\''--prefix=/some/dir'\'''
libdir='${exec_prefix}/lib64'

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue26971] python v3.5.1: sys.paths not respecting DESTDIRS and DESTSHARED

[Xavier de Gaye]

Xavier de Gaye added the comment:

Johannes, what are the values of CONFIG_ARGS and libdir in the config.log of 
your Linux SuSE.

--
nosy: +xdegaye

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue26971] python v3.5.1: sys.paths not respecting DESTDIRS and DESTSHARED

[Johannes S.]

Johannes S. added the comment:

Maybe my last comment was not clear enogth. I used the tarballs from 3.5 and 
3.6 which are linked in my last comment. I extracted them and run the the 
following commands on Arch (64 Bit) and Linux SuSE 13.1 (64 Bit):

mkdir build
cd build
../configure --prefix=/some/dir
make
make install

The path `/some/dir` is a placeholder. The path did not exist before running 
this commands. After running them on Linux SuSE, I discovered that 
`libpython3.5m.a`, `pkgconfig/` and `python3.5/lib-dynload` was placed in 
`/some/dir/lib64` instead of `/some/dir/lib`. On Arch, everything is placed in 
`/some/dir/lib` but I have the same behavior if I add 
`--libdir=/some/dir/lib64` to `configure`. With other words: `--libdir` seems 
to have a default value of "EPREFIX/lib64" instead of "EPREFIX/lib" on my 
instance of Linux SuSE. Maybe `configure` uses some global configurations here?

The problem is, that `sys.path` does point to `/some/dir/lib/lib-dynload` in 
all cases described above. Since `python3.5/lib-dynload` may be placed in 
`lib64`, this may cause that python does not run properly after installing it.

(Unfortunately, I cannot say much about the configuration of "my instance of 
Linux SuSE" since I am not the person who set it up. It is a server of my 
university.)

--
status: pending -> open

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue26971] python v3.5.1: sys.paths not respecting DESTDIRS and DESTSHARED

[Ned Deily]

Ned Deily added the comment:

Sorry, it is no longer clear to me exactly what problem(s) and solution are 
being proposed here.  When dealing with installation problems like this, we 
have to be *very* precise: here's what I started with on what platform, here 
are the contents of the relevant directories and/or files before I start, here 
are exactly the steps I took, here are the results I expected, and here are the 
results I observed.  Using a downloaded tarball and the steps in @yaro-yaro's 
initial message, I see no change in /usr/lib64; note, there *may* have been 
Python .so files installed there by system packages but that should be 
irrelevant to building and installing your own Python.  I also could not 
reproduce @jojo's recipe as best I understand it and don't see how it could 
produce any change in /usr/lib64.  Changing the value of --libdir is a whole 
different matter and not relevant to the original problem.  Also the title of 
the issue refers to DESTDIR and DESTSHARED but nowhere in the body of the issue 
a
 re these variables directly referenced, so I have to assume they aren't being 
explicitly set.

Unless someone can better demonstrate an actual problem here, I'm going to 
close this issue.

--
status: open -> pending

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue26971] python v3.5.1: sys.paths not respecting DESTDIRS and DESTSHARED

[Johannes S.]

Johannes S. added the comment:

I tried it again and I also tried 3.6.0a1 now. 3.6.0a1 has the issue as well. I 
have downloaded the tarballs from 
https://www.python.org/downloads/release/python-351/ and 
https://www.python.org/downloads/release/python-360a1/.

I have run it on my Laptop (Arch Linux) now. The issue did *not* occur there. 
But I discovered that I can trigger a similar issue by specifying the libdir 
explicitly with

`../configure --prefix="/some/dir" --libdir="/some/dir/lib64"`.

I thing it would be reasonable to assume that both issues are related.

--
versions: +Python 3.6

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue26971] python v3.5.1: sys.paths not respecting DESTDIRS and DESTSHARED

[Ned Deily]

Ned Deily added the comment:

That's very odd!  I don't have a SuSE system available to test with but it is 
not clear to me why that would have different behavior because where the 
standard library extension modules directory (lib-dynload) is installed is 
controlled by the Python configure and Makefile and, in the vanilla copies 
downloadable from python.org, I can't find any relevant references to lib64 
(there are some in setup.py as far as where to look for linking with other 
library files).  Are you sure you are using an unpatched 3.5.1 source tarball 
downloaded from python.org?  And that any lib-dynload in /lib64 wasn't 
installed by SuSE?  When I follow the steps you give, I end up with the 
extension modules in ~/.opt/lib/python3.5/lib-dynload as expected.  I don't 
know what else to suggest.  Anyone else have any ideas?

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue26971] python v3.5.1: sys.paths not respecting DESTDIRS and DESTSHARED

[Johannes Spangenberg]

Johannes Spangenberg added the comment:

I can confirm this issue. I did run it on Linux SuSE 13.1 (64 Bit). Unlike 
other components, which are installed in `lib/`, `lib-dynload` is installed in 
`lib64/python3.5/`. But `sys.path` still points to `lib/python3.5/lib-dynload`. 
It did run in on :

mkdir build
cd build
../configure --prefix="${HOME}/.opt"
nice -n 19 make -j 6
make install

--
nosy: +Johannes Spangenberg

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue26971] python v3.5.1: sys.paths not respecting DESTDIRS and DESTSHARED

[Ned Deily]

Ned Deily added the comment:

Sorry, I'm not able to reproduce your results on a vanilla Debian system.  
Building from scratch with ./configure --prefix=/usr and make steps results in:

$ /usr/bin/python3.5
Python 3.5.1 (default, May 22 2016, 02:26:09)
[GCC 4.9.2] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import base64
>>> import sys, _struct
>>> _struct.__file__
'/usr/lib/python3.5/lib-dynload/_struct.cpython-35m-x86_64-linux-gnu.so'
>>> sys.path
['', '/usr/lib/python35.zip', '/usr/lib/python3.5', 
'/usr/lib/python3.5/plat-linux', '/usr/lib/python3.5/lib-dynload', 
'/home/sysadmin/.local/lib/python3.5/site-packages', 
'/usr/lib/python3.5/site-packages']
>>>

Is it possible you had a virtual environment in effect?  Try repeating with 
"/usr/bin/python3.5" and verifying the build timestamp.  As far as I know, an 
unpatched Python 3.5 will not attempt to install anything into /usr/lib64 by 
default.

--
nosy: +ned.deily

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue26971] python v3.5.1: sys.paths not respecting DESTDIRS and DESTSHARED

[Jaroslav Urban]

Jaroslav Urban added the comment:

just a remark, my system is

$uname -r
4.4.5-200.fc22.x86_64

and these python-related rpm archives are installed:

$rpm -qa | grep python
python-IPy-0.81-12.fc22.noarch
python-urllib3-1.13.1-3.fc22.noarch
libselinux-python-2.3-10.fc22.x86_64
python-kitchen-1.2.1-2.fc22.noarch
python-backports-1.0-5.fc22.x86_64
python3-gobject-3.16.2-1.fc22.x86_64
python3-slip-dbus-0.6.4-1.fc22.noarch
python-meh-0.40-1.fc22.noarch
python3-dbus-1.2.0-7.fc22.x86_64
python3-PyXB-1.2.4-2.fc22.noarch
python-augeas-0.5.0-2.fc22.noarch
python-libcomps-0.1.6-14.fc22.x86_64
python-libs-2.7.10-8.fc22.x86_64
python-pwquality-1.2.4-3.fc22.x86_64
libsemanage-python-2.3-6.fc22.x86_64
python-di-0.3-4.fc21.noarch
python3-requests-2.9.1-1.fc22.noarch
libxml2-python-2.9.3-1.fc22.x86_64
audit-libs-python-2.4.5-1.fc22.x86_64
python-dnf-langpacks-0.15.1-1.fc22.noarch
python-talloc-2.1.5-2.fc22.x86_64
python-pexpect-3.1-3.fc21.noarch
python-pip-6.0.8-1.fc22.noarch
python3-libs-3.4.2-6.fc22.x86_64
python3-cups-1.9.72-1.fc22.x86_64
python3-pycurl-7.19.5.1-3.fc22.x86_64
python-dnf-1.1.6-2.fc22.noarch
python3-humanize-0.5.1-1.fc22.noarch
python3-pip-6.0.8-1.fc22.noarch
python3-cairo-1.10.0-11.fc22.x86_64
python-blivet-1.0.10-1.fc22.noarch
python3-lxml-3.3.6-1.fc22.x86_64
python-pyudev-0.16.1-3.fc22.noarch
python-iniparse-0.4-15.fc22.noarch
python3-enchant-1.6.6-1.fc22.noarch
python3-systemd-231-4.fc22.x86_64
python3-urllib3-1.13.1-3.fc22.noarch
python-2.7.10-8.fc22.x86_64
python-coverage-4.0.3-1.fc22.x86_64
python-slip-0.6.4-1.fc22.noarch
python3-firewall-0.3.14.2-4.fc22.noarch
python3-sssdconfig-1.13.3-5.fc22.noarch
python-hawkey-0.6.2-2.fc22.x86_64
python2-pyparsing-2.1.0-2.fc22.noarch
python-xpyb-1.3.1-4.fc22.x86_64
python-setuptools-17.1.1-3.fc22.noarch
python3-setuptools-17.1.1-3.fc22.noarch
python-pycurl-7.19.5.1-3.fc22.x86_64
python-six-1.9.0-1.fc22.noarch
python-decorator-3.4.0-5.fc21.noarch
python-dmidecode-3.10.13-12.fc22.x86_64
python2-systemd-231-4.fc22.x86_64
python-requests-2.9.1-1.fc22.noarch
python-backports-ssl_match_hostname-3.5.0.1-1.fc22.noarch
policycoreutils-python-2.3-18.fc22.x86_64
python-slip-dbus-0.6.4-1.fc22.noarch
python-librepo-1.7.16-1.fc22.x86_64
langtable-python-0.0.34-1.fc22.noarch
python-firewall-0.3.14.2-4.fc22.noarch
python-chardet-2.2.1-2.fc22.noarch
python3-six-1.9.0-1.fc22.noarch
python3-chardet-2.2.1-2.fc22.noarch
python-meh-gui-0.40-1.fc22.noarch
libuser-python-0.62-1.fc22.x86_64
libselinux-python3-2.3-10.fc22.x86_64
libreport-python3-2.6.4-1.fc22.x86_64
python-urlgrabber-3.10.1-6.fc22.noarch
python-dnf-plugins-extras-common-0.0.11-1.fc22.noarch
python3-inotify-0.9.6-1.fc22.noarch
python3-slip-0.6.4-1.fc22.noarch
newt-python-0.52.18-1.fc22.x86_64
python-ntplib-0.3.2-3.fc21.noarch
dbus-python-1.2.0-7.fc22.x86_64
python3-decorator-3.4.0-5.fc21.noarch
rpm-python-4.12.0.1-14.fc22.x86_64
libreport-python-2.6.4-1.fc22.x86_64
python3-javapackages-4.3.2-6.fc22.noarch
python-sssdconfig-1.13.3-5.fc22.noarch
python3-3.4.2-6.fc22.x86_64
python-dnf-plugins-core-0.1.16-1.fc22.noarch
python-dnf-plugins-extras-migrate-0.0.11-1.fc22.noarch
python3-cssselect-0.9.1-5.fc22.noarch

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue26971] python v3.5.1: sys.paths not respecting DESTDIRS and DESTSHARED

[Jaroslav Urban]

New submission from Jaroslav Urban:

#wget https://www.python.org/ftp/python/3.5.1/Python-3.5.1.tar.xz
#xz -d Python-3.5.1.tar.xz
#tar xvf Python-3.5.1.tar
#cd Python-3.5.1
#./configure --prefix=/usr
#make
#make altinstall

---

so far so good

but afterwards

$python3.5
>>>import base64

results in

Traceback (most recent call last):
  File "", line 1, in 
  File "/usr/lib/python3.5/base64.py", line 10, in 
import struct
  File "/usr/lib/python3.5/struct.py", line 13, in 
from _struct import *
ImportError: No module named '_struct'

--

>>>import sys
>>>sys.path
['', '/usr/lib/python35.zip', '/usr/lib/python3.5', 
'/usr/lib/python3.5/plat-linux', '/usr/lib/lib-dynload', 
'/usr/lib/python3.5/site-packages']

--

this path is wrong '/usr/lib/lib-dynload'
correctly it should point to the '/usr/lib64/python3.5/lib-dynload' as per the 
destination folders generated and used via configure / make / make altinstall

thank you
yaro-yaro

--
components: Installation
files: _sysconfigdata.py
messages: 265069
nosy: yaro-yaro
priority: normal
severity: normal
status: open
title: python v3.5.1: sys.paths not respecting DESTDIRS and DESTSHARED
type: behavior
versions: Python 3.5
Added file: http://bugs.python.org/file42767/_sysconfigdata.py

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com