[issue24923] Append system paths in setup.py instead of prepending
Chris Hogan added the comment: Zach, 3.x had the desired behavior. We didn't have to make any changes. -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue24923> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24923] Append system paths in setup.py instead of prepending
Chris Hogan added the comment: I should be able to try it out today or tomorrow. I'll let you know. -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue24923> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue25589] test_ascii_formatd fails on Mac when built with Intel compiler
Chris Hogan added the comment: The Intel compiler team is looking into this issue. I'll keep everyone updated here. -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue25589> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue25589] test_ascii_formatd fails on Mac when built with Intel compiler
Changes by Chris Hogan <christopher.ho...@intel.com>: -- resolution: not a bug -> status: closed -> open ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue25589> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue25589] test_ascii_formatd fails on Mac when built with Intel compiler
Chris Hogan added the comment: I guess since no one can reproduce the error, it must be a problem with how I'm building it. We build our own dependencies (zlib, bzip, sqlite3, openssl, etc.) with the Intel compiler, so it could be any number of things causing the issue. Closing as not a bug. -- resolution: -> not a bug status: open -> closed ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue25589> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue25589] test_ascii_formatd fails on Mac when built with Intel compiler
New submission from Chris Hogan: I successfully built Python on OS X 10.10 with the Intel compiler v15. However, running the regression tests gives me a "segmentation fault: 11" on test_ascii_formated. I think this has to do with libffi, because when I build with the --use-system-ffi flag (using a libffi that I built) all the regression tests pass, but I get a seg fault when I try to import ctypes. Using python's libffi I can import ctypes, but I get seg faults in the tests. Looking at libffi's homepage, it looks like x86-64 Mac OS X isn't on the list of officially supported platforms. I tried contacting the libffi-discuss mailing list about this but have received no response in a month. Please let me know what other information I can provide. -- components: Macintosh, Tests messages: 254398 nosy: christopher.hogan, ned.deily, ronaldoussoren priority: normal severity: normal status: open title: test_ascii_formatd fails on Mac when built with Intel compiler type: crash versions: Python 2.7, Python 3.5 ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue25589> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue25589] test_ascii_formatd fails on Mac when built with Intel compiler
Chris Hogan added the comment: Ned, the test is in Lib/test/test_ascii_formatd.py. Sorry, I spelled it wrong originally. Also, I guess it's only in 2.7. My mistake. -- versions: -Python 3.5 ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue25589> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24973] CFLAGS for Visual Studio
New submission from Chris Hogan: This Visual Studio project change appends to the compiler flags any values in the CFLAGS environment variable. -- components: Build, Windows files: addcflags3_5.patch keywords: patch messages: 249427 nosy: christopher.hogan, paul.moore, r.david.murray, steve.dower, tim.golden, zach.ware priority: normal severity: normal status: open title: CFLAGS for Visual Studio versions: Python 2.7, Python 3.5 Added file: http://bugs.python.org/file40308/addcflags3_5.patch ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue24973> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24973] CFLAGS for Visual Studio
Changes by Chris Hogan <christopher.ho...@intel.com>: Added file: http://bugs.python.org/file40309/addcflags2_7.patch ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue24973> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24923] Append system paths in setup.py instead of prepending
New submission from Chris Hogan: Setup.py evaluates what's given in LDFLAGS and CPPFLAGS and CFLAGS. These variables are the usual mechanism to communicate custom paths/libs/defs to a build process. However, setup.py puts system paths in front of custom paths which makes it impossible to use these variables for providing search paths to overwrite system settings. This patch puts system paths at the end of the list to avoid this problem. Is there a rationale for prepending system paths? -- components: Build files: append-sys-paths.patch keywords: patch messages: 249054 nosy: christopher.hogan priority: normal severity: normal status: open title: Append system paths in setup.py instead of prepending type: behavior versions: Python 2.7 Added file: http://bugs.python.org/file40240/append-sys-paths.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24923 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8987] Distutils doesn't quote Windows command lines properly
Chris Hogan added the comment: Here's a change that might fix the trailing backslash problem for now without breaking anything. libpath-fix.patch only affects arguments that we know are paths. This happens before anything is quoted. This avoids the problem when something like 'C:\path with space\trailing backslash\' is passed to _nt_quote_args() and becomes 'C:\path with space\trailing backslash\'. The is escaped which mangles the string. I'm not sure if it's the responsibility of the user to not pass in such arguments, or of cpython to sanitize these things. Is this change harmless, or can you think of situations where it will break something? -- Added file: http://bugs.python.org/file40221/libpath-fix.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue8987 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue993766] bdist_dumb and --relative on Windows fails
Chris Hogan added the comment:
I think ensure_relative is incorrect. The comment in the function states:
Take the full path 'path', and make it a relative path. This is useful to
make 'path' the second argument to os.path.join().
However, according to the docs for os.path.join, if a component contains a
drive letter, all previous components are thrown away and the drive letter is
reset. This makes the result from ensure_relative a poor candidate as a
second argument to os.path.join on Windows because it will always contain a
drive letter which will always wipe out the first argument.
os.path.join('bar', 'c:foo')
'c:foo'
This is what happens when I try to build a simple distro with the command
python setup.py bdist_dumb --relative. In
Lib/distutils/command/bdist_dumb.py:bdist_dumb.run:
archive_root = os.path.join(self.bdist_dir,
ensure_relative(install.install_base))
the call is
os.path.join('build\\bdist.win-amd64\\dumb', 'C:path\\to\\python')
'C:path\\to\\python'
It seems to me that the intention is to return
'build\\bdist.win-amd64\\dumb\\path\\to\\python27'
Later in distutils.archive_util.make_archive, it tries to os.chdir into
'C:path\\to\\python', which it can't do because that's not an absolute path
(it's missing a '\' after 'C:').
As far as I can tell, the only thing the --relative flag does is to append the
python install path onto the build location and build the archive there.
However, this build location is temporary and gets deleted at the end of the
process, so I don't really see the point.
I think there are two options here:
1) Get rid of ensure_relative and do it like this:
archive_root = os.path.join(self.bdist_dir,
os.path.splitdrive(install.install_base)[1].lstrip(os.sep))
This is the only place ensure_relative is ever used anyway.
2) Keep ensure_relative and do it like this:
archive_root = os.path.join(self.bdist_dir,
os.path.splitdrive(ensure_relative(install.install_base))[1])
--
nosy: +christopher.hogan
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue993766
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8987] Distutils doesn't quote Windows command lines properly
Chris Hogan added the comment: Since issue 8972 has been resolved by fixing the broken behavior, I think we should just use list2cmdline. We could leave _nt_quote_args alone and replace the call to it in _spawn_nt with: cmd = [list2cmdline([arg]) for arg in cmd] I verified that this passes the high-level test I wrote. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue8987 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8987] Distutils doesn't quote Windows command lines properly
Changes by Chris Hogan christopher.ho...@intel.com: Added file: http://bugs.python.org/file40205/quote-args-ext.tar.gz ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue8987 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8987] Distutils doesn't quote Windows command lines properly
Chris Hogan added the comment: At Intel, we've run into problems with external modules giving paths to _nt_quote_args that contain trailing backslashes, which escapes the final quote and breaks the command. This fix takes care of special characters, trailing backslashes, and embedded quotes as in Matt's example. I've also added unit tests for these cases, as well as a high level test that builds an extension and defines some macros that contain quotes and special characters. setup.py - Includes a library directory with a trailing backslash. I compiled a simple library, test_module.lib, and put it in that directory to test the linking. This fails without my fix. The macro definitions also fail without this fix. testmodule.c - A simple C extension. It just makes sure everything worked and returns the string Success! As for current workarounds in setup scripts, I know numpy uses their own distutils. They wrote a quote_args() function that they use instead of _nt_quote_args(). It checks for spaces, but only if the argument isn't already quoted. It doesn't account for other special characters or trailing backslashes. -- nosy: +christopher.hogan Added file: http://bugs.python.org/file40204/quote-args.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue8987 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21167] float('nan') returns 0.0 on Python compiled with icc
Chris Hogan added the comment: From Clark Nelson: In my opinion, exactly how and where the macro is defined that indicates our conformance to the FP standard doesn't really matter. The point is that it is our intention to conform, at least to some degree and under some circumstances. Under those circumstances, it would be wrong to map (0 * x) to 0 without regard to what x might be. Clark -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21167 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21167] float('nan') returns 0.0 on Python compiled with icc
Chris Hogan added the comment: Producing NaN by Py_HUGE_VAL / Py_HUGE_VAL as in the suggested patch is unsafe as it can generate a FP exception during runtime. Also aggresive compiler FP optimizations can eliminate this calculation on compile-time. For this reason, we've used constant referencing in our fix, which will work regardless of how -fp-model is set. The problem is that the compiler is free to pre-compute the result as both values in 0*Inf are constants. An aggressively optimizing compiler could treat 0 * x = 0 no matter what x is. So under aggressive floating point optimizations setting we could get a wrong value, and that is indeed what happens. Another problem is that 0 * Inf along with resulting in a QNaN value should raise an invalid floating point exception flag. If the result is pre-computed at compile time, then the user won’t see the flag (it is another question whether the user wanted the flag or not originally). Our patch preserves both the value and the side effect, and leaves people free to build with the flags they want. -- nosy: +christopher.hogan Added file: http://bugs.python.org/file40162/intel-nan-safe.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21167 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
