Berkeley DB has been ported to the QNX Neutrino technology which is commonly referred to as QNX RTP (Real-Time Platform). Berkeley DB has not been ported to earlier versions of QNX, such as QNX 4.25.
The /bin/sh
utility
distributed with some QNX releases drops core when
running the GNU libtool script (which is used to build
Berkeley DB shared libraries). There are two
workarounds for this problem: First, only build static
libraries. You can disable building shared libraries
by specifying the configuration flag when configuring
Berkeley DB.
Second, build Berkeley DB using an alternate shell.
QNX distributions include an accessories disk with
additional tools. One of the included tools is the GNU
bash shell, which is able to run the libtool script.
To build Berkeley DB using an alternate shell, move
/bin/sh
aside, link or copy
the alternate shell into that location, configure,
build and install Berkeley DB, and then replace the
original shell utility.
Berkeley DB generates temporary files for use in transactionally protected file system operations. Due to the filename length limit of 48 characters in the QNX filesystem, applications that are using transactions should specify a database name that is at most 43 characters.
shm_open
(2) in
order to use mmap
(2)?
QNX requires that files mapped with
mmap
(2) be opened using
shm_open
(2). There are other
places in addition to the environment shared memory
regions, where Berkeley DB tries to memory map files
if it can.
The memory pool subsystem normally attempts to use
mmap
(2) even when using private
memory, as indicated by the DB_PRIVATE flag to
DB_ENV->open(). In the case of QNX, if an application is
using private memory, Berkeley DB will not attempt to
map the memory and will instead use the local cache.
On QNX, the primitives implementing mutexes consume system resources. Therefore, if an application unexpectedly fails, those resources could leak. Berkeley DB solves this problem by always allocating mutexes in the persistent shared memory regions. Then, if an application fails, running recovery or explicitly removing the database environment by calling the DB_ENV->remove() method will allow Berkeley DB to release those previously held mutex resources. If an application specifies the DB_PRIVATE flag (choosing not to use persistent shared memory), and then fails, mutexes allocated in that private memory may leak their underlying system resources. Therefore, the DB_PRIVATE flag should be used with caution on QNX.
Remove the build directory manually to clean up and proceed.