|
AIX
Special compile-time flags are required when compiling threaded applications on AIX. If you are compiling a threaded application, you must compile with the _THREAD_SAFE flag and load with specific libraries; for example, "-lc_r". Specifying the compiler name with a trailing "_r" usually performs the right actions for the system.
xlc_r ... cc -D_THREAD_SAFE -lc_r ...
The Berkeley DB library will automatically build with the correct options.
AIX 4.1 allows applications to map only 10 system shared memory segments. In AIX 4.3, this has been raised to 256K segments, but only if you set the environment variable "export EXTSHM=ON".
We are aware of some duplicate symbol warnings with this platform, but they do not appear to affect the correct operation of applications.
By default, Berkeley DB is built with _LARGE_FILES set to 1 to support the creation of "large" database files. However, this also affects how standard classes, like iostream, are named internally. When building your application, use a "-D_LARGE_FILES=1" compilation option, or insert "#define _LARGE_FILES 1" before any #include statements.
If you're running on AIX 4.1 or earlier, try changing the source code for os/os_open.c to always specify the O_LARGEFILE flag to the open(2) system call, and recompile Berkeley DB from scratch.
Also, the documentation for the IBM Visual Age compiler states that it does not not support the 64-bit filesystem APIs necessary for creating large files; the ibmcxx product must be used instead. We have not heard whether the GNU gcc compiler supports the 64-bit APIs or not.
Finally, to create large files under AIX, the filesystem has to be configured to support large files and the system wide user hard-limit for file sizes has to be greater than 1GB.
System include files (most commonly fcntl.h) in some releases of AIX, HP-UX and Solaris redefine "open" when large-file support is enabled for applications. This causes problems when compiling applications because "open" is a method in the Berkeley DB APIs. To work around this problem:
Copyright (c) 1996,2008 Oracle. All rights reserved.