[issue15018] Incomplete Python LDFLAGS and CPPFLAGS used for extension modules on posix
New submission from Marcus von Appen : If CPython is built and installed with additional CPPFLAGS and/or LDFLAGS on a posix platform, those flags are not passed to C extension modules, leaving users (in the worst case) lost without the ability to build and install C extension modules, if the flags are important for detecting include files or linking. Example: * Python shall be built with GNU pthreads (--with-pth) * The pth libs are not installed in any default location, CPP and LD know about, but somewhere else (e.g. /usr/local/lib/pth/ and /usr/local/include/pth/) * Appropriate CPPFLAGS="-I/usr/local/include/pth" and LDFLAGS="-L/usr/local/lib/pth" are defined in the environment for the build. Python gets built and installed. Result in /wherever/pythonX.X/config/Makefile: ... OPT= BASECFLAGS= -fno-strict-aliasing CFLAGS= $(BASECFLAGS) -pipe $(OPT) $(EXTRA_CFLAGS) ... CPPFLAGS= -I. -IInclude -I$(srcdir)/Include -I/usr/local/include/pth LDFLAGS=-L/usr/local/lib/pth ... Invocation of python-config --cflags: # python-config --cflags -I/whereever/include/pythonX.X -I/whereever/include/pythonX.X -fno-strict-aliasing -pipe Invocation of python-config --ldflags: # python-config --ldflags -L/whereever/lib/pythonX.X/config -lpth -lutil -lm -lpythonX.X So far, so problematic. Since Python.h incorporates pth.h, compiling something without defining the necessary CPPFLAGS manually will fail. Same for linking. The issue is *not* limited to --with-pth, but to any CPPFLAGS/LDFLAGS settings that are necessary to get CPython to work on the target platform. One might argue that CPPFLAGS should go to CFLAGS, but that contradicts the purpose of CPPFLAGS and CFLAGS. At least for posix-alike platforms (those for which _init_posix() is called in distutils/sysconfig.py), it is necessary that both, python-config as well as the distutils internals add the appropriate CPPFLAGS. It might be argued that one should use CFLAGS instead of CPPFLAGS for such important additional flags, but what shall be done with LDFLAGS then? -- assignee: eric.araujo components: Build, Distutils, Extension Modules messages: 162405 nosy: eric.araujo, marcusva, tarek priority: normal severity: normal status: open title: Incomplete Python LDFLAGS and CPPFLAGS used for extension modules on posix type: behavior versions: Python 2.6, Python 2.7, Python 3.1, Python 3.2 ___ Python tracker <http://bugs.python.org/issue15018> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16283] ctypes.util.find_library does not find all DLLs anymore
New submission from Marcus von Appen: ctypes.util.find_library does not seem to be able to find certain libraries in Python3.3 on Win32 platforms anymore, if the library suffix is omitted. For some reason, os.path.isfile() in ctypes.util.find_library returns False in those cases. Please try out the attached test script. This produces the following output on a Windows 7 x64 system for me (given that a OpenAL32.dll is installed): C:\>c:\Python27-x64\python.exe ct_test.py Python build: 2.7.3 (default, Apr 10 2012, 23:24:47) [MSC v.1500 64 bit (AMD64)] Path 'C:\Windows\system32' exists in $PATH: True File 'C:\Windows\system32\OpenAL32.dll' exists: True ctypes says for 'OpenAL32.dll': C:\Windows\system32\OpenAL32.dll ctypes says for 'OpenAL32': C:\Windows\system32\OpenAL32.dll C:\>c:\Python31-x64\python.exe ct_test.py Python build: 3.1.4 (default, Jun 12 2011, 14:16:16) [MSC v.1500 64 bit (AMD64)] Path 'C:\Windows\system32' exists in $PATH: True File 'C:\Windows\system32\OpenAL32.dll' exists: True ctypes says for 'OpenAL32.dll': C:\Windows\system32\OpenAL32.dll ctypes says for 'OpenAL32': C:\Windows\system32\OpenAL32.dll C:\>c:\Python32-x64\python.exe ct_test.py Python build: 3.2.3 (default, Apr 11 2012, 07:12:16) [MSC v.1500 64 bit (AMD64)] Path 'C:\Windows\system32' exists in $PATH: True File 'C:\Windows\system32\OpenAL32.dll' exists: True ctypes says for 'OpenAL32.dll': C:\Windows\system32\OpenAL32.dll ctypes says for 'OpenAL32': C:\Windows\system32\OpenAL32.dll C:\>c:\Python33-x64\python.exe ct_test.py Python build: 3.3.0 (v3.3.0:bd8afb90ebf2, Sep 29 2012, 10:57:17) [MSC v.1600 64 bit (AMD64)] Path 'C:\Windows\system32' exists in $PATH: True File 'C:\Windows\system32\OpenAL32.dll' exists: True ctypes says for 'OpenAL32.dll': C:\Windows\system32\OpenAL32.dll ctypes says for 'OpenAL32': None -- components: ctypes files: ct_test.py messages: 173315 nosy: marcusva priority: normal severity: normal status: open title: ctypes.util.find_library does not find all DLLs anymore type: behavior versions: Python 3.3 Added file: http://bugs.python.org/file27618/ct_test.py ___ Python tracker <http://bugs.python.org/issue16283> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue20397] distutils --record option does not validate existance of byte-compiled files
New submission from Marcus von Appen: Using the --record argument with distutils' install command currently assumes that all .py files can be compiled (and optimized) successfully. If this is not the case for whatever reason, you end up with invalid entries in the record list. install_lib._bytecode_filenames() should verify, if the file could be created successfully (by e.g. checking for its existence) or the util.byte_compile() function should return a value that indicates, if the byte-compiled (or optimized) file could be created, so that the subsequent call to _bytecode_filenames() receives a list with valid entries. The issue can be recreated with e.g. http://pypi.python.org/pypi/Products.PasswordResetTool, which will create invalid entries for skins/PasswordReset/pwreset_constructURL.py, which acts as template/fragment. -- components: Distutils messages: 209320 nosy: marcusva priority: normal severity: normal status: open title: distutils --record option does not validate existance of byte-compiled files type: behavior versions: Python 2.7, Python 3.1, Python 3.2, Python 3.3 ___ Python tracker <http://bugs.python.org/issue20397> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18008] python33-3.3.2 Parser/pgen: Permission denied
Marcus von Appen added the comment: This is a FreeBSD-specific problem with the Python 3.3 port. Using pmake (BSD's make implementation) leads to random errors on either generating pgen or executing pgen. This seems to happen since Python 3.3.1 randomly and is quite hard to reproduce. Switching to GNU make seems to solve the issue, but makes me wonder, if Python (from now on) relies on GNU make. -- nosy: +marcusva status: pending -> open ___ Python tracker <http://bugs.python.org/issue18008> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
