diff options
Diffstat (limited to 'README')
| -rw-r--r-- | README | 118 |
1 files changed, 79 insertions, 39 deletions
@@ -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? - -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. +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 threads ------------------- |