Unlike 3.2, 3.3 and 3.x, which add "-IObjects -IPython -IInclude" to
BASECPPFLAGS when building out-of-tree, 2.7 only needs to add -IInclude
(for Python-ast.h and graminit.h).
os.lchflags() are once again built on systems that support these
functions (*BSD and OS X). Also add new stat file flags for OS X
(UF_HIDDEN and UF_COMPRESSED). Also add additional tests for
os.chflags() and os.lchflags(). (Tests by Garrett Cooper)
svn+ssh://pythondev@svn.python.org/python/branches/py3k
........
r87698 | antoine.pitrou | 2011-01-03 19:53:50 +0100 (lun., 03 janv. 2011) | 4 lines
Issue #7716: Under Solaris, don't assume existence of /usr/xpg4/bin/grep in
the configure script but use $GREP instead. Patch by Fabian Groffen.
........
svn+ssh://pythondev@svn.python.org/python/branches/py3k
........
r85422 | antoine.pitrou | 2010-10-13 19:01:10 +0200 (Wed, 13 Oct 2010) | 6 lines
Followup to #9437: since LDFLAGS is now appended to LDSHARED in the Makefile,
don't do in configure as well.
Hopefully this will solve a Makefile parsing issue on the FreeBSD buildbots.
........
svn+ssh://pythondev@svn.python.org/python/branches/py3k
........
r86042 | benjamin.peterson | 2010-10-31 11:50:44 -0500 (Sun, 31 Oct 2010) | 1 line
add no output to with-system-ffi and with-system-expat
........
svn+ssh://pythondev@svn.python.org/python/branches/py3k
........
r84680 | antoine.pitrou | 2010-09-10 21:44:44 +0200 (ven., 10 sept. 2010) | 4 lines
Issue #941346: Improve the build process under AIX and allow Python to
be built as a shared library. Patch by Sébastien Sablé.
........
Only override the AC_PROG_CC determined CFLAGS if they were set by the user.
This restores the default behavior in the common case of not having CFLAGS
defined when running configure.
framework install of Python in your home directory (on OSX):
$ configure --enable-framework=${HOME}/Library/Frameworks
$ make && make install
Without this patch the framework would get installed just fine,
but 'make install' would try to install the application bundles
and command-line tools outside the user's home, which doesn't work
for non-admin users (and is bad form anyway).
1) A non-critical off-by-one error in pythonw
2) A problem in the configure script that caused
builds with '--enable-framework --enable-universalsdk=/'
to fail on OSX 10.6.
and that it doesn't default to the 10.4u SDK when that SDK does not exist.
(This affects OSX)
This patch should fix most of issue 4834, although I haven't gotten enough
information from the user to be sure.
- Issue #7714: Use ``gcc -dumpversion`` to detect the version of GCC on
MacOSX.
- Make configure look for util.h as well as libutil.h. The former
is the header file that on OSX contains the defition of openpty.
(Needed to compile for OSX 10.4 on OSX 10.6)
- Use the correct definition of CC to compile the pythonw executable
The previous implementation used execv(2) to run the real interpreter, which means that
you cannot use the arch(1) tool to select the architecture you want to use for a
universal build because that only affects the python/pythonw wrapper and not the actual
interpreter.
The new version uses posix_spawnv with a number of OSX-specific options that ensure that
the real interpreter is started using the same CPU architecture as the wrapper, and that
means that 'arch -ppc python' now actually works.
I've also changed the way that the wrapper looks for the framework: it is now linked to
the framework rather than hardcoding the framework path. This should make it easier to
provide pythonw support in tools like virtualenv.
properly, and use this to skip test_multiprocessing on platforms
where sem_open raises a signal. This should fix some FreeBSD buildbot
failures for test_multiprocessing.
On MacOSX 10.6 the CoreFoundation framework must be initialized on the main
thread, the constructor function in that framework will cause an SIGABRT when
it is called on any other thread.
Because a number of extension link (indirectly) to CoreFoundation and the
Python core itself didn't the interpreter crashed when importing some
extensions, such as _locale, on a secondary thread.
This fix ensures that Python is linked to CoreFoundation on OSX, which results
in the CoreFoundation constructor being called when Python is loaded. This
does not require code changes.
- add double endianness detection to configure script
- add configure-time check to see whether we can use inline
assembly to get and set x87 control word in configure script
- add functions to get and set x87 control word in Python/pymath.c
- add pyport.h logic to determine whether it's safe to use the
short float repr or not
to that README file with some explanation.
* Be more strict in the configure script: complain loudly when the user has
specified invalid combinations of OSX-specific configure arguments.
The error message refers to the Mac/README file for more information.
doko@python.org
Charles-François Natali
Trent Nelson
Mark Dickinson
Stefan Krah
Martin v. Löwis
Matthias Klose
Victor Stinner
Ned Deily
Georg Brandl
Antoine Pitrou
Stefan Krah
Benjamin Peterson
Marc-André Lemburg
Ronald Oussoren
Jesus Cea
Gregory P. Smith
Alexandre Vassalotti