[issue7679] Warning building 2.7 on OS X 10.6 libintl.h "Present But Cannot Be Compiled"
Nicholas Riley added the comment: You should be able to invoke the compiler like this: gcc -nostdinc -I/usr/include -F/System/Library/Frameworks ... which will remove /usr/local/include (and /Library/Frameworks). This also removes the compiler-specific include dir, so to be fully general you could postprocess $CC -v output to just filter /usr/local/include - it looks like the Clang driver is GCC-compatible as far as -v output goes. And in general, I guess this is really an Apple bug... -- nosy: +nriley ___ Python tracker <http://bugs.python.org/issue7679> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14104] Implement time.monotonic() on Mac OS X
Nicholas Riley added the comment: Attached is a patch which implements time.monotonic() using mach_absolute_time() / mach_timebase_info(). This was recommended by Apple in their technical Q&A 1398: https://developer.apple.com/library/mac/#qa/qa1398/ -- keywords: +patch nosy: +nriley Added file: http://bugs.python.org/file24798/monotonic.patch ___ Python tracker <http://bugs.python.org/issue14104> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12978] Figure out extended attributes on BSDs
Nicholas Riley added the comment: I've spent a few hours looking at xattr and the Linux/OS X (10.4+) implementations. Bob Ippolito's xattr module implements the OS X xattr interface on Linux, Solaris (9+) and FreeBSD. Linux and OS X are pretty close; FreeBSD and Solaris are substantially different from either and the Solaris implementation is somewhat incomplete/broken. The OS X differences from Linux are: • Instead of l* functions, the XATTR_NOFOLLOW option • XATTR_NOSECURITY and XATTR_NODEFAULT are in the headers but essentially unavailable as the kernel code always returns EINVAL for them. • XATTR_SHOWCOMPRESSION to expose the HFS compression stuff, which I can't imagine many people needing • XATTR_MAXNAMELEN (but no equivalent to XATTR_SIZE_MAX). Linux has a corresponding XATTR_NAME_MAX, which we should probably expose too. • XATTR_FINDERINFO_NAME and XATTR_RESOURCEFORK_NAME for some standard attribute names. I would imagine these are worth exposing. I don't see any problems supporting the currently exposed Linux API on OS X (I could probably find a usable value for XATTR_SIZE_MAX), but it's unclear if that is the right way to go forward. Suggestions? -- nosy: +nriley ___ Python tracker <http://bugs.python.org/issue12978> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12978] Figure out extended attributes on BSDs
Changes by Nicholas Riley : -- nosy: +bob.ippolito ___ Python tracker <http://bugs.python.org/issue12978> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14104] Implement time.monotonic() on Mac OS X
Nicholas Riley added the comment: timebase.numer and timebase.denom are always 1 in practice (see the "note" in the tech Q&A); I included them for completeness, but maybe it's just better to not bother? -- ___ Python tracker <http://bugs.python.org/issue14104> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14104] Implement time.monotonic() on Mac OS X
Nicholas Riley added the comment: OK, you have a point :-) New patch attached. -- Added file: http://bugs.python.org/file24804/monotonic-2.patch ___ Python tracker <http://bugs.python.org/issue14104> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14277] time.monotonic docstring does not mention the time unit returned
New submission from Nicholas Riley : Currently: >>> help(time.monotonic) Help on built-in function monotonic in module time: monotonic(...) monotonic() -> float Monotonic clock. The reference point of the returned value is undefined so only the difference of consecutive calls is valid. -- components: Library (Lib) messages: 155518 nosy: nriley priority: normal severity: normal status: open title: time.monotonic docstring does not mention the time unit returned versions: Python 3.3 ___ Python tracker <http://bugs.python.org/issue14277> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14277] time.monotonic docstring does not mention the time unit returned
Nicholas Riley added the comment: According to http://juliusdavies.ca/posix_clocks/clock_realtime_linux_faq.html, CLOCK_REALTIME can go backwards. CLOCK_MONOTONIC_RAW is best where available (like QueryPerformanceFrequency / mach_absolute_time) and CLOCK_MONOTONIC is pretty good. So I have updated both the docs for time.monotonic and time.wallclock to hopefully better explain things... may need to be another issue here too. -- keywords: +patch Added file: http://bugs.python.org/file24809/monotonic-doc.patch ___ Python tracker <http://bugs.python.org/issue14277> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14292] OS X installer build script doesn't set $CXX, so it ends up as "c++"
New submission from Nicholas Riley :
% python build-installer.py \
--sdk-path=/Developer/SDKs/MacOSX10.6.sdk \
--universal-archs=intel \
--dep-target=10.6
Settings:
* Source directory: /Users/nicholas/src/cpython
* Build directory: /tmp/_py
* SDK location: /Developer/SDKs/MacOSX10.6.sdk
* Third-party source: /tmp/_py/third-party
* Deployment target: 10.6
* Universal architectures: ('i386', 'x86_64')
* C compiler: gcc-4.2
[...]
Building a universal python for intel architectures
[...]
checking for c++... c++
configure: WARNING:
By default, distutils will build C++ extension modules with "c++".
If this is not intended, then set CXX on the configure command line.
--
assignee: ronaldoussoren
components: Macintosh
messages: 155663
nosy: ned.deily, nriley, ronaldoussoren
priority: normal
severity: normal
status: open
title: OS X installer build script doesn't set $CXX, so it ends up as "c++"
versions: Python 3.3
___
Python tracker
<http://bugs.python.org/issue14292>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13507] Modify OS X installer builds to package liblzma for the new lzma module
Nicholas Riley added the comment: The configure problem is soluble with --disable-dependency-tracking (it was the -M* options to gcc that caused the problem); something similar is used for SQLite. The attached patch should do it... -- keywords: +patch nosy: +nriley Added file: http://bugs.python.org/file24827/xz.patch ___ Python tracker <http://bugs.python.org/issue13507> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14299] OS X installer build script: permissions not ensured
New submission from Nicholas Riley : The OS X installer build script does not ensure that files had the correct permissions when being packaged; some files' permissions were affected by your umask when running the build script, and others by the permissions of the source tree. This patch sets the umask, so script-created files get correct permissions, wraps shutil.copy so it does the same thing, and adapts the existing os.walk-based permissions fixer to run over everything else. It also removes group writability for the Python framework, as this is more secure and consistent with how Apple installs Python in 10.7 and later. If you need to install a Python package without being root, either use virtualenv/pythonv, ~/Library or ~/.local. Ned Deily and I discussed this at the PyCon sprints and he will update the documentation to match. -- assignee: ronaldoussoren components: Macintosh files: perm.patch keywords: patch messages: 155716 nosy: nriley, ronaldoussoren priority: normal severity: normal status: open title: OS X installer build script: permissions not ensured type: behavior versions: Python 3.3 Added file: http://bugs.python.org/file24837/perm.patch ___ Python tracker <http://bugs.python.org/issue14299> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14299] OS X installer build script: permissions not ensured
Changes by Nicholas Riley : -- nosy: +ned.deily ___ Python tracker <http://bugs.python.org/issue14299> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14299] OS X installer build script: permissions not ensured
Nicholas Riley added the comment: I don't have time to check it, but it's easy enough to test - set your umask to 077 and try building an installer, see if the files get the correct permissions when installed. I would hope tutorials would tell users to install the packages somewhere else, but you're probably right - sudo is the path of least resistance and is even less secure. -- ___ Python tracker <http://bugs.python.org/issue14299> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue818201] distutils: clean does not use build_base option from build
Nicholas Riley added the comment: Good to know - thanks! -- ___ Python tracker <http://bugs.python.org/issue818201> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
