Merged Misc/AtheOS-NOTES into the platform-specific section. Rewrote the

bsddb module build note to reflect the inclusion of bsddb3 and the demotion
of the old bsddb module.
This commit is contained in:
Skip Montanaro 2003-01-04 04:05:51 +00:00
parent 69bf8f3f4e
commit 56d8301809
1 changed files with 78 additions and 38 deletions

116
README
View File

@ -594,48 +594,88 @@ Cygwin: With recent (relative to the time of writing, 2001-12-19)
News regarding these platforms with more recent Cygwin
versions would be appreciated!
AtheOS: From Octavian Cerna <tavy at ylabs.com>:
Before building:
Make sure you have shared versions of the libraries you
want to use with Python. You will have to compile them
yourself, or download precompiled packages.
Recommended libraries:
ncurses-4.2
readline-4.2a
zlib-1.1.4
Build:
$ ./configure --prefix=/usr/python
$ make
Python is always built as a shared library, otherwise
dynamic loading would not work.
Testing:
$ make test
Install:
# make install
# pkgmanager -a /usr/python
AtheOS issues:
- large file support: due to a stdio bug in glibc/libio,
access to large files may not work correctly. fseeko()
tries to seek to a negative offset. ftello() returns a
negative offset, it looks like a 32->64bit
sign-extension issue. The lowlevel functions (open,
lseek, etc) are OK.
- sockets: AF_UNIX is defined in the C library and in
Python, but not implemented in the system.
- select: poll is available in the C library, but does not
work (It does not return POLLNVAL for bad fds and
hangs).
- posix: statvfs and fstatvfs always return ENOSYS.
- disabled modules:
- mmap: not yet implemented in AtheOS
- nis: broken (on an unconfigured system
yp_get_default_domain() returns junk instead of
error)
- dl: dynamic loading doesn't work via dlopen()
- resource: getrimit and setrlimit are not yet
implemented
- if you are getting segmentation faults, you probably are
low on memory. AtheOS doesn't handle very well an
out-of-memory condition and simply SEGVs the process.
Tested on:
AtheOS-0.3.7
gcc-2.95
binutils-2.10
make-3.78
Configuring the bsddb and dbm modules
-------------------------------------
XXX Shouldn't this section be rewritten now that we use Sleepycat's
BSDDB 4.0?
Beginning with Python version 2.3, the PyBsddb package
<http://pybsddb.sf.net/> was adopted into Python as the bsddb package,
exposing a set of package-level functions which provide
backwards-compatible behavior. Only versions 3.1 through 4.1 of
Sleepycat's libraries provide the necessary API, so older versions
aren't supported through this interface. The old bsddb module has
been retained as bsddb185, though it is not built by default. Users
wishing to use it will have to tweak Modules/Setup to build it. The
dbm module will still be built against the Sleepycat libraries if
other preferred alternatives (ndbm, gdbm) are not found, though
versions of the Sleepycat library prior to 3.1 are not considered.
Configuring the bsddb module can sometimes be a bit tricky. This module
provides a Python interface to the Berkeley DB library. As of this writing
several versions of the underlying library are in common use (versions 1.85,
2.x, 3.x, and 4.x). The file formats across the various versions tend to be
incompatible. Some Linux distributions install multiple versions by
default. It is important that compatible versions of header files and
libraries are used when building bsddb. To make matters worse, version 1.85
of Berkeley DB has known bugs in its hash file implementation, but is still
the most widely available version of the library. Many people build bsddb
with version 1.85 but aren't aware of the bugs. This affects people using
the anydbm and dbhash modules because they are both use Berkeley DB's hash
file format as a side effect of calling bsddb.hashopen.
To try and remedy this problem, beginning with Python version 2.3 a number
of changes to the bsddb build process were made. First, and most important,
the bsddb module will not be built with version 1.85 unless the relevant
lines in setup.py are uncommented first and no other higher-numbered
versions are found. Second, matching versions of the library and include
files must be found. Third, searching is performed in order, starting from
version 4 and proceeding to version 2 (or version 1 if it is enabled).
Version-independent libraries and header files (e.g. /usr/lib/libdb.a and
/usr/include/db.h) are never considered. They must be in version-specific
directories or have version-specific filenames (e.g. /usr/lib/libdb-3.2.so
and /usr/include/db3/db_185.h).
Since the bsddb module is programmed using the Berkeley DB version 1 API,
the underlying library must be configured with the --enable-compat185 flag.
Most vendor-provided distributions are so-configured. This is generally
only an issue if you build Berkeley DB from source.
All this affects the dbm module as well. There are several dbm-compliant
APIs provided by different libraries, including ndbm, gdbm and Berkeley DB.
The build process for dbm would previously use the version 1.85 library,
thus extending the potential hash file corruption to the dbm module as well.
The dbm module will use the library and include files found for the bsddb
module if neither ndbm nor gdbm libraries are found.
Configuring threads
-------------------