New submission from Xavier de Gaye:
The error messages:
running install_lib
creating /lib/python3.7
error: could not create '/lib/python3.7': Permission denied
make[1]: *** [Makefile:1449: sharedinstall] Error 1
The command that triggers this failure:
_PYTHON_PROJECT_BASE=/tmp/android-makesetup/build/python3.7-android-21-armv7
_PYTHON_HOST_PLATFORM=linux-arm
PYTHONPATH=/tmp/android-makesetup/build/python3.7-android-21-armv7/build/lib.linux-arm-3.7:/src/python/master/Lib
_PYTHON_SYSCONFIGDATA_NAME=_sysconfigdata_m_linux_ python
/src/python/master/setup.py install \
--prefix=/ \
--install-scripts=//bin \
--install-platlib=//lib/python3.7/lib-dynload \
--root=/tmp/android-makesetup/build/python3.7-install-android-21-armv7/
Note how some paths in the setup.py options start with two slashes.
The problem is that change_root() in Lib/distutils/util.py cannot concatenate
'root' with 'pathname' as 'pathname' starts with two slashes and therefore
cannot be made relative by just removing one slash. The behavior of
change_root() is correct (although it could be made more robust by calling
os.path.normpath() first before removing the first slash) because according to
POSIX a pathname starting with two slashes is implementation defined (but not
when starting with three or more slashes). And normpath respects this rule:
>>> from os.path import normpath
>>> normpath('//tmp')
'//tmp'
>>> normpath('///tmp')
'/tmp'
However for most posix systems (possibly except Cygwin ?), a path starting with
two slashes is the same path as the path starting with one slash.
The problem lies with the Makefile. A workaround for the user is to set the
--exec-prefix option to '/./' instead of '/' when running configure and this
fixes the problem, the installation is successfull. So a fix could be to swap
'/' for '/./' in configure itself.
Maybe there is a better solution.
References:
issue 1676135:
The changes made by this issue have excluded the case of '/' as there was a
concern at that time that the sys.prefix value would be wrong. I have checked
that sys.prefix is correct when '/' is changed to '/./' (on configure command
line). This is because the determination of sys.prefix made by Lib/site.py is
quite different now from what it was 10 years ago.
issue 9674:
This is exactly the same issue as this one. I have preferred to open a new
issue here because the discussion on issue 9674 is focused on making changes to
distutils while the problem is actually in the posixly incorrect use of paths
starting with double slashes in the Makefile.
----------
components: Build
messages: 299718
nosy: xdegaye
priority: normal
severity: normal
status: open
title: 'make install' fails when exec_prefix is '/' and DESTDIR not empty
type: behavior
versions: Python 2.7, Python 3.5, Python 3.6, Python 3.7
_______________________________________
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue31114>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
