[issue38472] GCC detection in setup.py is broken
Alex Grund added the comment: Yes this is still an issue. I'm trying to compile Python on an HPC system which uses modules (see e.g. LMod). Yes with LC_ALL=C it does write "gcc version 9.1.0 ..." -- status: pending -> open ___ Python tracker <https://bugs.python.org/issue38472> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue38472] GCC detection in setup.py is broken
New submission from Alex Grund : `setup.py` runs ` -E -v - /dev/null` to figure out include and library paths from the compiler in the function `add_gcc_paths`. However sample output from the compiler is: Es werden eingebaute Spezifikationen verwendet. COLLECT_GCC=g++ Ziel: x86_64-pc-linux-gnu Konfiguriert mit: ../configure --enable-languages=c,c++,fortran --enable-lto --enable-checking=release --disable-multilib --enable-shared=yes --enable-static=yes --enable-threads=posix --enable-plugins --enable-gold=default --enable-ld --with-plugin-ld=ld.gold --prefix=/sw/installed/GCCcore/9.1.0 --with-local-prefix=/sw/installed/GCCcore/9.1.0 --enable-bootstrap --with-isl=/dev/shm/easybuild-build/GCCcore/9.1.0/dummy-/gcc-9.1.0/stage2_stuff Thread-Modell: posix gcc-Version 9.1.0 (GCC) COLLECT_GCC_OPTIONS='-E' '-v' '-shared-libgcc' '-mtune=generic' '-march=x86-64' /software/haswell/GCCcore/9.1.0/bin/../libexec/gcc/x86_64-pc-linux-gnu/9.1.0/cc1 -E -quiet -v -iprefix /software/haswell/GCCcore/9.1.0/bin/../lib/gcc/x86_64-pc-linux-gnu/9.1.0/ - -mtune=generic -march=x86-64 nicht vorhandenes Verzeichnis »/software/haswell/GCCcore/9.1.0/bin/../lib/gcc/x86_64-pc-linux-gnu/9.1.0/../../../../x86_64-pc-linux-gnu/include« wird ignoriert doppeltes Verzeichnis »/software/haswell/GCCcore/9.1.0/bin/../lib/gcc/../../lib/gcc/x86_64-pc-linux-gnu/9.1.0/include« wird ignoriert doppeltes Verzeichnis »/software/haswell/GCCcore/9.1.0/bin/../lib/gcc/../../lib/gcc/x86_64-pc-linux-gnu/9.1.0/include-fixed« wird ignoriert nicht vorhandenes Verzeichnis »/software/haswell/GCCcore/9.1.0/bin/../lib/gcc/../../lib/gcc/x86_64-pc-linux-gnu/9.1.0/../../../../x86_64-pc-linux-gnu/include« wird ignoriert doppeltes Verzeichnis »/sw/installed/GCCcore/9.1.0/include« wird ignoriert da es ein Nicht-Systemverzeichnis ist, das ein Systemverzeichnis dupliziert Suche für »#include "..."« beginnt hier: Suche für »#include <...>« beginnt hier: /sw/installed/binutils/2.32-GCCcore-9.1.0/include /sw/installed/zlib/1.2.11-GCCcore-9.1.0/include /software/haswell/GCCcore/9.1.0/bin/../lib/gcc/x86_64-pc-linux-gnu/9.1.0/include /software/haswell/GCCcore/9.1.0/bin/../lib/gcc/x86_64-pc-linux-gnu/9.1.0/include-fixed /sw/installed/GCCcore/9.1.0/include /usr/include Ende der Suchliste. COMPILER_PATH=/software/haswell/GCCcore/9.1.0/bin/../libexec/gcc/x86_64-pc-linux-gnu/9.1.0/:/software/haswell/GCCcore/9.1.0/bin/../libexec/gcc/ LIBRARY_PATH=/software/haswell/GCCcore/9.1.0/bin/../lib/gcc/x86_64-pc-linux-gnu/9.1.0/:/software/haswell/GCCcore/9.1.0/bin/../lib/gcc/:/sw/installed/GCCcore/9.1.0/lib64/../lib64/:/sw/installed/GCCcore/9.1.0/lib/../lib64/:/software/haswell/GCCcore/9.1.0/bin/../lib/gcc/x86_64-pc-linux-gnu/9.1.0/../../../../lib64/:/lib/../lib64/:/usr/lib/../lib64/:/sw/installed/binutils/2.32-GCCcore-9.1.0/lib/:/sw/installed/zlib/1.2.11-GCCcore-9.1.0/lib/:/sw/installed/GCCcore/9.1.0/lib64/:/sw/installed/GCCcore/9.1.0/lib/:/software/haswell/GCCcore/9.1.0/bin/../lib/gcc/x86_64-pc-linux-gnu/9.1.0/../../../:/lib/:/usr/lib/ COLLECT_GCC_OPTIONS='-E' '-v' '-shared-libgcc' '-mtune=generic' '-march=x86-64' So the correct matcher would be "gcc-Version", maybe in addition to "gcc version" Due to this the setup fails to build e.g. bzip2 modules as the include and lib paths are passed in via CPATH and LIBRARY_PATH only (module system on HPC system) -- components: Build messages: 354629 nosy: Alex Grund priority: normal severity: normal status: open title: GCC detection in setup.py is broken type: compile error versions: Python 2.7, Python 3.5, Python 3.6, Python 3.7, Python 3.8, Python 3.9 ___ Python tracker <https://bugs.python.org/issue38472> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue38472] GCC detection in setup.py is broken
Alex Grund added the comment: This seems to be a locale issue. So a solution would be to use `LC_ALL=C` before invoking the compiler (or the cross-platform equivalent) -- ___ Python tracker <https://bugs.python.org/issue38472> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue38549] Compiler build paths and related environment variables are ignored for native builds
New submission from Alex Grund : In e.g. Linux users can set CPATH and LIBRARY_PATH to a list of paths considered by e.g. GCC, Clang, ... as if they were passed to `-I`, `-L` These paths show up in the verbose compiler output too. However in native builds (not cross-compiling) these variables/directories are ignored which leads to failure of e.g. building the BZip2 extension (among others). Use case: On HPC modules are used, which means e.g. BZip2 is not installed into a system directory but into some other folder and CPATH, LIBRARY_PATH, LD_LIBRARY_PATH, ... are modified so it can be found by compiler and runtime. However the Python build script does not find it as it ignores those "compiler paths". This did work ages ago, but was broken when it was decided that compiler paths (output of `gcc -E -v`) is no longer used for native builds and that function was later even renamed: https://github.com/python/cpython/commit/32f5fdd7f4213743fe2f6eedd0fe2108f3157021#diff-2eeaed663bd0d25b7e608891384b7298R514 I propose to rename the function back to its original name and use it always. -- components: Build messages: 355073 nosy: Alex Grund priority: normal severity: normal status: open title: Compiler build paths and related environment variables are ignored for native builds type: compile error versions: Python 2.7, Python 3.5, Python 3.6, Python 3.7, Python 3.8, Python 3.9 ___ Python tracker <https://bugs.python.org/issue38549> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43219] shutil.copy raises IsADirectoryError when the directory does not actually exist
Alex Grund added the comment: The changelog wrongfully links to https://bugs.python.org/issue41928 instead of this issue. Also the fix introduced a regression: Trying to copy a directory now raises a FileNotFoundError -- nosy: +Alex Grund ___ Python tracker <https://bugs.python.org/issue43219> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue45234] copy_file raises FileNotFoundError when src is a directory
New submission from Alex Grund :
After https://bugs.python.org/issue43219 was resolved the function now shows
faulty behavior when the source is a directory:
`copy_file('/path/to/dir', '/target')` throws a FileNotFoundError while
previously it was a IsADirectoryError which is clearly correct.
See https://github.com/python/cpython/pull/27049#issuecomment-921647431
--
components: Library (Lib)
messages: 402057
nosy: Alex Grund
priority: normal
severity: normal
status: open
title: copy_file raises FileNotFoundError when src is a directory
versions: Python 3.10, Python 3.11, Python 3.9
___
Python tracker
<https://bugs.python.org/issue45234>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue39286] Configure includes LIBS but does not pass it to distutils
New submission from Alex Grund : When configuring with `LIBS=-lpthread` env var set, the pthread detection assumes that no flag is necessary and distutils will build all extensions without any flag for pthreads. This will make them fail, when they use certain pthread symbols on certain platforms Example: On Power9 libpthread is a linker script which does not only link in the dynamic library but also a static part which contains e.g. pthread_atfork. As the extension is linked against libpython and that is linked against libpthread the extension has access to all symbols from the dynamic library, but not to any from the static library (if one exists). This makes extensions fail to build on Power9. Related issue as an example: https://github.com/scipy/scipy/issues/11323 EasyBuild is one example that builds Python with that env var set: https://github.com/easybuilders/easybuild-framework/issues/3154 Very related to https://bugs.python.org/issue31769 as the issue is similar: Flag passed during configure not used by distutils. -- components: Build, Distutils messages: 359721 nosy: Alex Grund, dstufft, eric.araujo priority: normal severity: normal status: open title: Configure includes LIBS but does not pass it to distutils versions: Python 2.7, Python 3.5, Python 3.6, Python 3.7, Python 3.8, Python 3.9 ___ Python tracker <https://bugs.python.org/issue39286> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
