[ #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.
This patch allows the readline module to build cleanly with GNU
readline 4.2 without breaking the build for earlier GNU readline
versions. The configure script checks for the presence of
rl_completion_matches in libreadline.
Add configure option --enable-unicode.
Add config.h macros Py_USING_UNICODE, PY_UNICODE_TYPE, Py_UNICODE_SIZE,
SIZEOF_WCHAR_T.
Define Py_UCS2.
Encode and decode large UTF-8 characters into single Py_UNICODE values
for wide Unicode types; likewise for UTF-16.
Remove test whether sizeof Py_UNICODE is two.
Mac/macglue.c into the core interpreter. This file contains the glue code that
allows extension modules for Mac toolboxes to live in different shared libraries
but still communicate with each other. The glue code is controlled by the
USE_MAC_TOOLBOX_GLUE define. [checked in for Jack]
into Makefile.pre.in; the configure script will only determine the basename
of the file.
This fixes installation of a Python built using C++, reported by Greg
Wilson.
builds during which he forgot to uncomment crucial library lines in
Setup, walks into Guido's East End nightclub with a tactical nuclear
weapon on his shoulder. Said nuclear weapon is promptly deployed
exactly where it will do the most good, right in the middle of
configure.in.
With this patch, the set of libraries autoconfigured in is extended to
include ndbm, gdbm, and crypt. This essentially eliminates any need to
tweak Setup for a normal Linux build.
"'E was a fair man. Cruel, but fair."
of dbmmodule dynamically by default (otherwise it can pull in
dependencies with libdb that croak pybsddb3). This change moves the
Setup line for dbmmodule to Setup.config.in.
- when compiling with GCC on Solaris, use "$(CC) -shared" instead
of "$(CC) -G" to generate .so files
- when compiling with GCC on any platform, add "-fPIC" to OPT
(without this, "$(CC) -shared" dies horribly)
regardless of whether the system getopt() does what we want. This avoids the
hassle with prototypes and externs, and the check to see if the system
getopt() does what we want. Prefix optind, optarg and opterr with _PyOS_ to
avoid name clashes. Add new include file to define the right symbols. Fix
Demo/pyserv/pyserv.c to include getopt.h itself, instead of relying on
Python to provide it.
-Wstrict-prototypes options. This will make it a lot easier to keep
warnings under control in the first place in the future.
There is one known warning at this time, caught by the -Wstrict-prototypes
option. In Modules/main.c, the declaration of getopt() without parameters
gets a complaint (rightly) that it is not a proper prototype. The lack of
a complete prototype information should be corrected when the right
portability conditions have been identified.
Approved by the Guido.
Tony Lownds: [ Patch #101816 ] Fixes shared modules on Mac OS X
1. Mac OS X is recognized by the Next-ish host recognition code as
"Darwin/1.2"
2. When specifying just --with-dyld, modules can compile as shared
3. --with-dyld and --with-next-framework, modules can compile as
shared
4. --with-suffix=.exe, and Lib/plat-darwin1.2 is being made, the regen
script invokes python as python.exe
[I had to reformat this patch a bit to make it work. Please test!]
Dan Wolfe: [ Patch #101823 ] Fix Darwin POSIX Thread redefinition
The patch below fixes the redefinition problem in Darwin with
_POSIX_THREADS. I'm not sure if this is the correct long term fix but
for now it fixes the problem and the fix is specific to Darwin.
Dan Wolfe: [ Patch #101824 ] On Darwin, remove unrecognized option
`-OPT:Olimit=0'
After many, many, many compiles, I finally got itchy of this warning
cluttering up the output... so I scratched (Darwin configs only) and
it's gone! :-)
test -d "$directory"
to
test ! -z "directory" -a -d "directory"
Apparently, on SunOS 4.1.4_JL (and other?) OSes, -d on an empty string
always returns true. This closes SF bug #115392.
-D_HPUX_SOURCE and also turns on long long support.
Suggestion by stnor@sweden.hp.com (Stefan Norberg).
Please test this if you have access to HP-UX!!!
I can't test this, so I'm just checking it in with blind faith in Andy.
I've tested that it doesn't broeak a non-Pth build on Linux.
Changes include:
- There's a --with-pth configure option.
- Instead of _GNU_PTH, we test for HAVE_PTH.
- Better signal handling.
- (The config.h.in file is regenerated in a slightly different order.)
This allows dbmmodule.c to use either without having to add additional
options to the Modules/Setup file or make source changes.
(At least some Linux systems use gdbm to emulate ndbm, but only install
the ndbm.h header as /usr/include/gdbm/ndbm.h.)
enable it), but db.h was not found, the WITH_LIBDB macros was still being
defined, resulting in compilation errors. Also added a short explain when
bsddb support wasn't enabled (because db.h wasn't found) when the user
explicitly used --with-libdb on the configure command line.
- Fix bug in thread_pthread.h::PyThread_get_thread_ident() where
sizeof(pthread) < sizeof(long).
- Add 'configure' for:
- SIZEOF_PTHREAD is pthread_t can be included via <pthread.h>
- setting Monterey system name
- appropriate CC,LINKCC,LDSHARED,OPT, and CCSHARED for Monterey
- Add section in README for Monterey build
which I can cast void* to and back again without losing information".
In pyport.h, we typedef Py_uintptr_t to mean this thing, which if the
platform supports, will be uintptr_t (otherwise, other accomodations
are made).
- Don't call both AC_CHECK_FUNCS and AC_REPLACE_FUNC for 'hypot', as the
latter already does everything the former does (because it's implemented as
a call to the former.)
- Don't call AC_CHECK_FUNC() without any 'action' clauses or with an action
clause that just defines HAVE_<function>. Instead, call AC_CHECK_FUNCS,
which defines 'HAVE_<function>' of itself, possibly with aditional 'action'
clauses.
No checks are removed by this patch, only moved around, and some duplicates
are removed.
disables it. The gc test is moved to just after the thread test, as
is the wctype-functions test.
Modules/Setup.config is generated instead of Modules/Setup.thread.
Applied SF patch #100684 (loewis) to fix help alignment bug.
threads use --without-threads. No extra tests of thread/compiler
combinations have been added.
--with(out)-thread and --with(out)-threads are completely
interchangeable.
--with-threads still supports the =DIRECTORY option for specifying
where to find thread libraries.
This patch adds the openpty() and forkpty() library calls to posixmodule.c,
when they are available on the target
system. (glibc-2.1-based Linux systems, FreeBSD and BSDI at least, probably
the other BSD-based systems as well.)
Lib/pty.py is also rewritten to use openpty when available, but falls
back to the old SGI method or the "manual" BSD open-a-pty
code. Openpty() is necessary to use the Unix98 ptys under Linux 2.2,
or when using non-standard tty names under (at least) BSDI, which is
why I needed it, myself ;-) forkpty() is included for symmetry.
create shared extensions rather than 'ld -G'. This ensures that shared
extensions link against libgcc.a, in case there are any functions in the
GCC runtime not already in the Python core.
Solaris 2 has stub implementations of the POSIX thread functions such as
pthread_detach in libc. This means that configure tries to use them without
-lpthread, then the test of pthread_create fails and the configuration
falls back to the Solaris thread library. This patch moves the test for
pthread_create in -lpthread ahead of the test for pthread_detach in libc.
The patch also ensures that -lpthread is at the start of the library list
when linking, to pick up POSIX thread semantics for fork (see below).
Justification.
Use of POSIX threads on Solaris ensures that the fork() call only runs the
thread that called fork() in the child. This is desirable to prevent (for
example) parent server or database threads running in the child. Sun's
-lthread library uses a traditional fork() which replicates all the
parent's threads in the child. I find this undesirable.
Digression.
The configure.in seems to always test for -lthread even if a POSIX library
is found. I'm not enough of a configure.in wizard to decide whether this is
desirable or how to fix it. It is also irrelevant to this patch - I just
spotted it while testing.
End of Digression.
least on Solaris (sometimes it's Unix98, sometimes it conforms to an
early draft).
Properly generate config.h.in using autoheader instead of editing it
manually; thanks, Guido!
Duzan, for AIX, to support C++ objects with static initializers, when
using the genuine IBM C++ compiler (namely xlC/xlC_r).
See accompanying patches to acconfig.h and importdl.c.
The following patches (relative to 1.5.2b1) enable Python dynamic
loading to work on NetBSD platforms that use ELF (presnetly mips and
alpha systems). They automaticly determine wether the system is ELF or
a.out rather than using astatic list of platforms so that when other
NetBSD platforms move to ELF, python will continue to work without
change.
it seems harmless for other platforms. It plays tricks with the name
of the library used to link with. Apparently DG/UX really wants a
shared library to link with if it wants shared modules to use symbols
from the library. I'm not sure why this wasn't an issue with 1.4;
DG/UX seems to be the only platform where moving to a single library
made things harder!
BTW This adds a target to create libpython$(VERSION).so; however this
target is *only* for DG/UX.
- add test for strptime (not used by the core but needed by Marc Lemburg's
Date object).
- Test for GNU ld on Solaris; need to add an extra linker option to
export symbols in that case.
enabled. This is done through a substitution in Modules/Setup.thread(.in).
Bill Janssen will be happy. The original idea was by Lele Gaifax (though
I changed the implementation to use a separate file).
from the main program to shared libraries. On mklinux, the old
'-rdynamic' doesn't work; the new '-Xlinker -export-dynamic' works
both there and on Intel Linux platforms.
Makefile.in: run config.status in "make recheck".
configure.in: add test for hypot().
config.h.in, configure: since configure.in changed.
rest: the usual boring stuff.
more trouble than it's worth at CWI and most other people seem to
install Python in the default (/usr/local) anway. Changed comment
describing --prefix in Makefile.in
Michael W. Hudson
Jack Jansen
Fred Drake
Martin v. Löwis
Neil Schemenauer
Guido van Rossum
Andrew M. Kuchling
Thomas Wouters
Jeremy Hylton
Sjoerd Mullender
Eric S. Raymond
Barry Warsaw
Greg Ward
Skip Montanaro
Vladimir Marangozov
Trent Mick
Peter Schneider-Kamp
Greg Stein