HP-UX
Prev  Chapter 27.  Building Berkeley DB for UNIX/POSIX  Next

HP-UX

  1. I can't specify the DB_SYSTEM_MEM flag to DB_ENV->open().

    The shmget(2) interfaces are not always used on HP-UX, even though they exist, because anonymous memory allocated using shmget(2) cannot be used to store the standard HP-UX msemaphore semaphores. For this reason, it may not be possible to specify the DB_SYSTEM_MEM flag on some versions of HP-UX. (We have seen this problem only on HP-UX 10.XX, so the simplest workaround may be to upgrade your HP-UX release.)

  2. I can't specify both the DB_PRIVATE and DB_THREAD flags to DB_ENV->open().

    It is not possible to store the standard HP-UX msemaphore semaphores in memory returned by malloc(3) in some versions of HP-UX. For this reason, it may not be possible to specify both the DB_PRIVATE and DB_THREAD flags on some versions of HP-UX. (We have seen this problem only on some older HP-UX platforms, so the simplest workaround may be to upgrade your HP-UX release.)

  3. I can't compile and run multithreaded applications.

    Special compile-time flags are required when compiling threaded applications on HP-UX. If you are compiling a threaded application, you must compile with the _REENTRANT flag:

    cc -D_REENTRANT ...

    The Berkeley DB library will automatically build with the correct options.

  4. An ENOMEM error is returned from DB_ENV->open() or DB_ENV->remove().

    Due to the constraints of the PA-RISC memory architecture, HP-UX does not allow a process to map a file into its address space multiple times. For this reason, each Berkeley DB environment may be opened only once by a process on HP-UX; that is, calls to DB_ENV->open() will fail if the specified Berkeley DB environment has been opened and not subsequently closed.

  5. When compiling with gcc, I see the following error: 
    #error "Large Files (ILP32) not supported in strict ANSI mode."

    We believe this is an error in the HP-UX include files, but we don't really understand it. The only workaround we have found is to add -D__STDC_EXT__ to the C preprocessor defines as part of compilation.

  6. When using the Tcl or Perl APIs (including running the test suite), I see the error "Can't shl_load() a library containing Thread Local Storage".

    This problem happens when HP-UX has been configured to use pthread mutex locking, and an attempt is made to call Berkeley DB using the Tcl or Perl APIs. We have never found any way to fix this problem as part of the Berkeley DB build process. To work around the problem, rebuild tclsh or Perl, and modify its build process to explicitly link it against the HP-UX pthread library (currently /usr/lib/libpthread.a).

  7. When running an executable that has been dynamically linked against the Berkeley DB library, I see the error "Can't find path for shared library" even though I correctly set the SHLIB_PATH environment variable.

    By default, some versions of HP-UX ignore the dynamic library search path specified by the SHLIB_PATH environment variable. To work around this, specify the "+s" flag to ld when linking, or run the following command on the executable that is not working:

    chatr +s enable -l /full/path/to/libdb-3.2.sl ...
  8. When building for an IA64 processor, I see either bus errors or compiler warnings about converting between unaligned types (#4232). How can I resolve them?

    Berkeley DB requires that data types containing members with different sizes be aligned in a consistent way. The HP-UX compiler does not provide this alignment property by default.

    The compiler can be made to generate adequately aligned data by passing the +u1 option to the compiler. See the HP documentation about the +u1 flag for more information.

  9. I see errors about "open64" when building Berkeley DB applications.

    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:

    1. Avoid including the problematical system include files in source code files which also include Berkeley DB include files and call into the Berkeley DB API.
    2. Before building Berkeley DB, modify the generated include file db.h to itself include the problematical system include files.
    3. Turn off Berkeley DB large-file support by specifying the --disable-largefile configuration option and rebuilding.
Prev  Up  Next
FreeBSD  Home  IRIX