MacOSX: if we cannot use -undefined dynamic_lookup (such as on 10.2 or earlier)
we link extension directly against the dynamic library in the framework in
stead of against the framework. This will fix building extensions for 2.3
after 2.4 has been installed too.
to make using "-undefined dynamic_lookup" for linking extensions more
automatic on 10.3 and later. So if we're on that platform and
MACOSX_DEPLOYMENT_TARGET is not set we now set it to the current OSX
version during configure. Additionally, distutils will pick up the
configure-time value by default.
Will backport.
because GNU/k*BSD uses gnu pth to provide pthreads, but will also happen on any
system that does the same.
python fails to build because it doesn't detect gnu pth in pthread
emulation. See C comments in patch for details.
patch taken from http://bugs.debian.org/264315
[ 960406 ] unblock signals in threads
although the changes do not correspond exactly to any patch attached to
that report.
Non-main threads no longer have all signals masked.
A different interface to readline is used.
The handling of signals inside calls to PyOS_Readline is now rather
different.
These changes are all a bit scary! Review and cross-platform testing
much appreciated.
of hard linking against the framework).
If $MACOSX_DEPLOYMENT_TARGET is set, and >= 10.3, during configure we
setup extensions to link with dynamic lookup. We also record the
value in the Makefile.
Distutils checks whether a value for MACOSX_DEPLOYMENT_TARGET was
recorded in the Makefile, and if it was insists that the current
value matches.
This is only a partial fix because it only applies to 2.4, and the
"two python problem" exists with Python 2.3 shipped with MacOSX 10.3,
which we have no influence over.
two framework builds (in /Library and /System/Library) to coexist
with distutils linking against the right one.
Should be backported to 2.3, but getting Apple-supplied Python to pick
up these fixes is going to be non-trivial.
Cygwin's pthread_sigmask() implementation appears to be buggy. This
patch works around this problem by using sigprocmask() instead.
This patch is implemented in a general way so it could be used by other
platforms too. If this approach is deemed too risky, then I can work up
a patch that just hacks Python/thread_pthread.h for Cygwin.
Note that I tested this patch against 2.3c1 under Red Hat Linux 8.0 too.
[snip]
And finally, I need someone to regenerate pyconfig.h.in and configure
with the same versions of the autotools that are normally used by
Python.
Neal kindly regenerated pyconfig.h.in and configure for me.
- In the top level Makefile, the argument to -install_name should be
prepended with /System/Library/Frameworks/, so it is an absolute path.
- In the top level Makefile, because of 2), RUNSHARED needs to be set to
DYLD_FRAMEWORK_PATH=<path to local framework> and $(RUNSHARED) prepended
to the $(MAKE) lines in the frameworkinstallmaclib and
frameworkinstallapps targets.
scope of the _XOPEN_SOURCE and _POSIX_C_SOURCE symbols, including:
- getloadavg()
- typedefs for u_int, u_long, u_char, u_short, ushort & uint
These are now all defined under the control of a __BSD_VISIBLE symbol.
The lack of the typedefs causes several extension modules to build
incorrectly or not at all, and is the cause of failures reported for
test_socket and test_tempfile on this platform
(see python-dev: 29/6/03, pieterb@gewis.nl, "Running tests on freebsd5")
This change does not appear to be needed in the 2.2 branch.
For reasons unknown this suddenly started to matter (since Martin's 1.396
checkin? But why?), at least on MacOSX. Added a real test similar to the
getpgrp argument test.
for specific platforms. Use this to add plat-mac and
plat-mac/lib-scriptpackages on MacOSX. Also tested for not having adverse
effects on Linux, and I think this code isn't used on Windows anyway.
Fixes#661521.
Need to make sure that preprocessor directives start in first column.
This means we can't indent code which has preprocessor directives,
nor have a space between [ #include for example.
compiler flags which are necessary to get a clean compile. The former is
for user-specified optimizer, debug, trace fiddling. See patch 640843.
Add /sw/lib and /sw/include to setup.py search paths on Darwin to take
advantage of fink goodies.
Add scriptsinstall target to Makefile to install certain scripts from
Tools/scripts directory.
knows about plat-mac subdirectories, and configure adds a variable
EXTRAPLATDIR. These together take care of copying Lib/plat-mac to
the destination on darwin.
Adding plat-mac is still done with a .pth file which is only created when
you do a framework build. I'm not 100% happy with this, but fixing it
really needs a functional pythonw in non-framework builds, and I don't
think I can do that before 2.3a1 (but I'll try:-).
Check for readline 2.2 features. This should make it possible to
compile readline.c again with GNU readline versions 2.0 or 2.1; this
ability was removed in readline.c rev. 2.49. Apparently the older
versions are still in widespread deployment on older Solaris
installations. With an older readline, completion behavior is subtly
different (a space is always added).
us to completely decouple the framework from the executable, so we
can use a two-level namespace.
- Do framework builds with a twolevel namespace.
- Reorganized the code that creates the minimal framework in the build
directory, to make it more robust against incomplete frameworks (from
earlier aborted builds, or builds of previous Python versions).
for the time module, because somehow configure won't define the
symbols HAVE_STRUCT_TM_TM_ZONE, HAVE_TM_ZONE, and HAVE_TZNAME in this
case.
I've got no time to research this further, so I leave it in Jeremy and
Martin's capable hands to find a different solution for True64 (or to
devise a way to get the time tests to succeed while defining
_XOPEN_SOURCE).
This gets compilation of posixmodule.c to succeed on Tru64 and does no
harm on Linux. We may need to undefine it on some platforms, but
let's wait and see.
Martin says:
> I think it is generally the right thing to define _XOPEN_SOURCE on
> Unix, providing a negative list of systems that cannot support this
> setting (or preferably solving whatever problems remain).
>
> I'd put an (unconditional) AC_DEFINE into configure.in early on; it
> *should* go into confdefs.h as configure proceeds, and thus be active
> when other tests are performed.
The staticforward define was needed to support certain broken C
compilers (notably SCO ODT 3.0, perhaps early AIX as well) botched the
static keyword when it was used with a forward declaration of a static
initialized structure. Standard C allows the forward declaration with
static, and we've decided to stop catering to broken C compilers. (In
fact, we expect that the compilers are all fixed eight years later.)
I'm leaving staticforward and statichere defined in object.h as
static. This is only for backwards compatibility with C extensions
that might still use it.
XXX I haven't updated the documentation.
OSX framework build process. Things fixed/modified:
- the filesystem case-sensitivity test now works for builds outside
the source directory
- various other fixes for building outside the source directory
- python.app now has a target in the main Makefile
- WASTE and AquaTk are found more automatically
library. Since multiple versions can be installed simultaneously, it's
crucial that you only select libraries and header files which are compatible
with each other. Version checking is done from highest version to lowest.
Building using version 1 of Berkeley DB is disabled by default because of
the hash file bugs people keep rediscovering. It can be enabled by
uncommenting a few lines in setup.py. Closes patch 553108.
This patch complies with the following request found
near the top of configure.in:
# This is for stuff that absolutely must end up in pyconfig.h.
# Please use pyport.h instead, if possible.
I tested this patch under Cygwin, Win32, and Red
Hat Linux. Python built and ran successfully on
each of these platforms.
[ 559250 ] more POSIX signal stuff
Adds support (and docs and tests and autoconfery) for posix signal
mask handling -- sigpending, sigprocmask and sigsuspend.
This patch complies with the following request found
near the top of configure.in:
# This is for stuff that absolutely must end up in pyconfig.h.
# Please use pyport.h instead, if possible.
I tested this patch under Cygwin, Win32, and Red
Hat Linux. Python built and ran successfully on
each of these platforms.
Highlights: import and friends will understand any of \r, \n and \r\n
as end of line. Python file input will do the same if you use mode 'U'.
Everything can be disabled by configuring with --without-universal-newlines.
See PEP278 for details.
or libraries also look for thread_detach. SGI has thread_create in libc
but complete pthread support only in -lpthread. Fixes#522393.
2.2.1 candidate.Killed by signal 2.
[ #417634 ] configuring without C++ compiler name
by checking that we're not about to try to compile C++ files with "yes".
Now we wait for the system where the C++ compiler *is* called yes...
used the default Darwin/* for the old code. Reversed those tests so
that compatibility code is in a switch leg with a specific version and
newer systems take the default leg.
This should allow Python to build on OSX 10.1.1 (which jumps from Darwin/1.4
to Darwin/5.1 due to a new numbering scheme).
routines. As of 10.1 using Carbon will crash Python if no window server is
available (ssh connection, console mode, MacOSX Server). This fixes bug
#466907.
A result of this mod is that the default 8bit encoding on OSX is now ASCII,
for the time being. Also, the extension modules that need the Carbon
framework now explicitly include it in setup.py.
1. configure doesn't handle HP-UX release numbers
(e.g., B.11.00), resulting in MACHDEP = "hpuxB".
2. After checking for wchar.h, configure doesn't
include it when checking the size of wchar_t.
(Python 2.2b1 on HP-UX 11.00)
This adds unsetenv to posix, and uses it in the __delitem__ method of
os.environ.
(XXX Should we change the preferred name for putenv to setenv, for
consistency?)
This is a big one, touching lots of files. Some of the platforms
aren't tested yet. Briefly, this changes the return value of the
os/posix functions stat(), fstat(), statvfs(), fstatvfs(), and the
time functions localtime(), gmtime(), and strptime() from tuples into
pseudo-sequences. When accessed as a sequence, they behave exactly as
before. But they also have attributes like st_mtime or tm_year. The
stat return value, moreover, has a few platform-specific attributes
that are not available through the sequence interface (because
everybody expects the sequence to have a fixed length, these couldn't
be added there). If your platform's struct stat doesn't define
st_blksize, st_blocks or st_rdev, they won't be accessible from Python
either.
(Still missing is a documentation update.)
supplied values are the most "normal" or "common" values found for
recent 32 bit machines. This now seems to work to build Python 2.2
for the ARM processor used on the iPAQ.
by bbrox@bbrox.org / lionel.ulmer@free.fr.
This adds a configure check and if all goes well turns on the
PTHREAD_SCOPE_SYSTEM thread attribute for new threads.
This should remove the need to add tiny sleeps at the start of threads
to allow other threads to be scheduled.
support on Linux (and Solaris, I expect) for real.
The necessary symbols are defined once and for all,
under the assumption that they won't harm elsewhere.
out of the box on OSX 10.1. Untested by me (except for not having adverse
effects on 10.0.4) but it looks good, for now. Eventually we should not
trigger on the darwin version but test for something, but until I have
the time to install 10.1 myself I have no clue what to test on.
It would be nice if this got in to the 2.2a3 distribution.
I don't know what difference it makes, but '/' indeed makes less sense
as an include dir than '.', so I'm changing the default. Just so I
can close the bug. ;-)
I believe this works on Linux (tested both on a system with large file
support and one without it), and it may work on Solaris 2.7.
The changes are twofold:
(1) The configure script now boldly tries to set the two symbols that
are recommended (for Solaris and Linux), and then tries a test
script that does some simple seeking without writing.
(2) The _portable_{fseek,ftell} functions are a little more systematic
in how they try the different large file support options: first
try fseeko/ftello, but only if off_t is large; then try
fseek64/ftell64; then try hacking with fgetpos/fsetpos.
I'm keeping my fingers crossed. The meaning of the
HAVE_LARGEFILE_SUPPORT macro is not at all clear.
I'll see if I can get it to work on Windows as well.
- Do not compile unicodeobject, unicodectype, and unicodedata if Unicode is disabled
- check for Py_USING_UNICODE in all places that use Unicode functions
- disables unicode literals, and the builtin functions
- add the types.StringTypes list
- remove Unicode literals from most tests.
- Give a warning if you're on a case-insensitive filesystem and have
not specified --with-suffix.
- Don't require --with-dyld, it is now default for OSX/Darwin (suggested
by Martin v. Loewis)
- Don't define _POSIX_THREADS on Darwin, it's done by standard headers already
(fix by Tony Lownds)
- Don't use the Mac subtree anymore, the routines relevant to OSX/Darwin
have moved to a new file Python/mactoolboxglue.c.
the --with-suffix=.exe, but it seems that that is also true for cygwin
(or not? should I automatically set it?)
- Got --with-next-framework to build on OSX. This is only the build bit,
the install still has to be done manually. Moreover, the Python build order
isn't really suited to frameworks (where you want to do 'build lib',
'install lib and framework', 'link executable against installed framework'
in that order).
Also note that it isn't just Linux nice() that is broken: at least FreeBSD
and BSDI also have this problem. os.nice() should probably just be emulated
using getpriority()/setpriority(), if they are available, but I'll get to
that later.