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.
diff --git a/README b/README
index 293f989..47925ec 100644
--- a/README
+++ b/README
@@ -594,48 +594,88 @@
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
-------------------