[issue2466] os.path.ismount doesn't work for mounts the user doesn't have permission to see
Changes by Ross Burton <[EMAIL PROTECTED]>: -- title: os.path.ismount doesn't work for NTFS mounts -> os.path.ismount doesn't work for mounts the user doesn't have permission to see versions: +Python 2.5 -Python 2.4 ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue2466> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2466] os.path.ismount doesn't work for NTFS mounts
New submission from Ross Burton <[EMAIL PROTECTED]>:
I'm not sure why this is, but ismount doesn't always work for me. It
appears to fail on NTFS mounts.
$ mount
...
/dev/sda1 on /media/windows type ntfs (ro,noexec,nosuid,nodev,user=ross)
redbeard.local:/home on /media/home type nfs
(rw,user=ross,noatime,rsize=65536,wsize=65536,retry=1,nfsvers=3,posix,intr,addr=192.168.1.67)
$ python
Python 2.4.5 (#2, Mar 12 2008, 00:15:51)
[GCC 4.2.3 (Debian 4.2.3-2)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> ismount("/media/windows")
False
>>> ismount("/media/home")
True
--
components: Library (Lib)
messages: 64370
nosy: rossburton
severity: normal
status: open
title: os.path.ismount doesn't work for NTFS mounts
type: behavior
versions: Python 2.4
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue2466>
__
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2466] os.path.ismount doesn't work for NTFS mounts
Ross Burton <[EMAIL PROTECTED]> added the comment: Aha. The contents of the mount point are only accessible by root: $ stat /media/windows/.. stat: cannot stat `/media/windows/..': Permission denied This falls into the except block, so false is returned. If ismount() used os.path.dirname() instead of appending "..", then this wouldn't happen. __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue2466> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue45749] Silently fails to build hashlib if openssl has disabled algorithms
New submission from Ross Burton : If my openssl is built with no-scrypt then the Python build of hashlib fails (as EVP_PBE_scrypt isn't present), but the overall compile succeeds. -- components: Build messages: 405954 nosy: rossburton2 priority: normal severity: normal status: open title: Silently fails to build hashlib if openssl has disabled algorithms ___ Python tracker <https://bugs.python.org/issue45749> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue45749] Silently fails to build hashlib if openssl has disabled algorithms
Change by Ross Burton : -- versions: +Python 3.10 ___ Python tracker <https://bugs.python.org/issue45749> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue45749] Silently fails to build hashlib if openssl has disabled algorithms
Ross Burton added the comment: Cool, glad to see the additional checks. -- ___ Python tracker <https://bugs.python.org/issue45749> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue36125] Cannot cross-compile to more featureful but same tune
New submission from Ross Burton : My build machine is a Haswell Intel x86-64. I'm cross-compiling to x86-64, with -mtune=Skylake -avx2. During make install PYTHON_FOR_BUILD loads modules from the *build* Lib/ which contain instructions my Haswell can't execute: | _PYTHON_PROJECT_BASE=/data/poky-tmp/master/work/corei7-64-poky-linux/python3/3.7.2-r0/build _PYTHON_HOST_PLATFORM=linux-x86_64 PYTHONPATH=../Python-3.7.2/Lib _PYTHON_SYSCONFIGDATA_NAME=_sysconfigdata_m_linux_x86_64-linux-gnu python3.7 -v -S -m sysconfig --generate-posix-vars ;\ Illegal instruction -- components: Build messages: 336688 nosy: rossburton priority: normal severity: normal status: open title: Cannot cross-compile to more featureful but same tune versions: Python 3.7 ___ Python tracker <https://bugs.python.org/issue36125> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue36125] Cannot cross-compile to more featureful but same tune
Ross Burton added the comment: >From what I can tell: configure.ac sets PYTHON_FOR_BUILD like this if cross-compiling: PYTHON_FOR_BUILD='_PYTHON_PROJECT_BASE=$(abs_builddir) _PYTHON_HOST_PLATFORM=$(_PYTHON_HOST_PLATFORM) PYTHONPATH=$(shell test -f pybuilddir.txt && echo $(abs_builddir)/`cat pybuilddir.txt`:)$(srcdir)/Lib _PYTHON_SYSCONFIGDATA_NAME=_sysconfigdata_$(ABIFLAGS)_$(MACHDEP)_$(MULTIARCH) '$interp Note how PYTHONPATH is set to the source and build paths for Lib/. The intention appears to be that the sysconfig.py in the build is used. In my case that directory is also full of shared libraries that Python happily loads, and then fails. -- ___ Python tracker <https://bugs.python.org/issue36125> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue36125] Cannot cross-compile to more featureful but same tune
Ross Burton added the comment:
strace disagrees. By putting strace in PYTHON_FOR_BUILD and then invoking make
sharedmods:
| openat(AT_FDCWD,
"/data/poky-tmp/master/work/corei7-64-poky-linux/python3/3.7.2-r0/build/build/lib.linux-x86_64-3.7/_heapq.cpython-37m-x86_64-linux-gnu.so",
O_RDONLY|O_CLOEXEC) = 3
| read(3,
"\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\320\20\0\0\0\0\0\0"..., 832) =
832
| fstat(3, {st_mode=S_IFREG|0755, st_size=62104, ...}) = 0
| mmap(NULL, 23880, PROT_READ, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x7f93d7cb9000
| mmap(0x7f93d7cba000, 4096, PROT_READ|PROT_EXEC,
MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x1000) = 0x7f93d7cba000
| mmap(0x7f93d7cbb000, 4096, PROT_READ, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3,
0x2000) = 0x7f93d7cbb000
| mmap(0x7f93d7cbc000, 12288, PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x2000) = 0x7f93d7cbc000
| close(3)= 0
| mprotect(0x7f93d7cbc000, 4096, PROT_READ) = 0
| --- SIGILL {si_signo=SIGILL, si_code=ILL_ILLOPN, si_addr=0x7f93d7cbab10} ---
| +++ killed by SIGILL (core dumped) +++
| Illegal instruction
| Makefile:625: recipe for target 'sharedmods' failed
We do have patches but I don't think they affect this part of the build.
--
___
Python tracker
<https://bugs.python.org/issue36125>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue36125] Cannot cross-compile to more featureful but same tune
Ross Burton added the comment: That's exactly the glitch. I'm cross-compiling to a more powerful IA process from IA. This *is* a cross-compilation but the triple is the same. Assuming that you can rely on the loader to not open target binaries when they're on the path to load from is unwise. -- ___ Python tracker <https://bugs.python.org/issue36125> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue34585] Don't use AC_RUN_IFELSE to determine float endian
New submission from Ross Burton : Currently configure.ac uses AC_RUN_IFELSE to determine the byte order of floats and doubles. This hurts when cross-compiling because a default is set, resulting in Python silently falling back to sub-optimal codepaths. A partial improvement would be to not set a fallback, to force the user to set the right byte order explicitly. However this test can be done without running anything. autoconf-archive has a macro that uses a carefully constructed double that encodes to an ASCII string in the binary, which is then examined using grep. Evil genius. Attached is a POC using this. Currently the autoconf-archive macro only handles big and little endian not the ARM OABI mixed-endian format, so configure.ac assumes if the byte order is unknown then it's the crazy mixed-endian. To be honest OABI is so old now, I don't believe anyone actually uses it anymore: everyone still on ARMv4 should have moved to EABI many years ago, and the mixed-endian support could be removed from Py3 in the future. -- components: Build files: 0001-Don-t-do-runtime-test-to-get-float-byte-order.patch keywords: patch messages: 324627 nosy: rossburton priority: normal severity: normal status: open title: Don't use AC_RUN_IFELSE to determine float endian versions: Python 3.8 Added file: https://bugs.python.org/file47788/0001-Don-t-do-runtime-test-to-get-float-byte-order.patch ___ Python tracker <https://bugs.python.org/issue34585> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue34585] Don't use AC_RUN_IFELSE to determine float endian
Change by Ross Burton : -- pull_requests: +8543 stage: -> patch review ___ Python tracker <https://bugs.python.org/issue34585> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
