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.