diff options
Diffstat (limited to 'db/docs/ref/build_unix/notes.html')
-rw-r--r-- | db/docs/ref/build_unix/notes.html | 138 |
1 files changed, 138 insertions, 0 deletions
diff --git a/db/docs/ref/build_unix/notes.html b/db/docs/ref/build_unix/notes.html new file mode 100644 index 000000000..dcb975e3c --- /dev/null +++ b/db/docs/ref/build_unix/notes.html @@ -0,0 +1,138 @@ +<!--$Id: notes.so,v 10.42 2001/01/09 18:49:53 bostic Exp $--> +<!--Copyright 1997, 1998, 1999, 2000 by Sleepycat Software, Inc.--> +<!--All rights reserved.--> +<html> +<head> +<title>Berkeley DB Reference Guide: Architecture independent FAQs</title> +<meta name="description" content="Berkeley DB: An embedded database programmatic toolkit."> +<meta name="keywords" content="embedded,database,programmatic,toolkit,b+tree,btree,hash,hashing,transaction,transactions,locking,logging,access method,access methods,java,C,C++"> +</head> +<body bgcolor=white> + <a name="2"><!--meow--></a> <a name="3"><!--meow--></a> +<table><tr valign=top> +<td><h3><dl><dt>Berkeley DB Reference Guide:<dd>Building Berkeley DB for UNIX systems</dl></h3></td> +<td width="1%"><a href="../../ref/build_unix/test.html"><img src="../../images/prev.gif" alt="Prev"></a><a href="../../ref/toc.html"><img src="../../images/ref.gif" alt="Ref"></a><a href="../../ref/build_unix/aix.html"><img src="../../images/next.gif" alt="Next"></a> +</td></tr></table> +<p> +<h1 align=center>Architecture independent FAQs</h1> +<p><ol> +<p><li><b>When compiling with gcc, I get unreferenced symbols, e.g.,: +<p><blockquote><pre>symbol __muldi3: referenced symbol not found +symbol __cmpdi2: referenced symbol not found</pre></blockquote></b> +<p>On systems where they're available (e.g., HP-UX, Solaris), Berkeley DB uses +64-bit integral types. As far as we can tell, some versions of gcc +don't support these types. The simplest workaround is to reconfigure +Berkeley DB using the --disable-bigfile configuration option, and then rebuild. +<hr size=1 noshade> +<p><li><b>My C++ program traps during a failure in a DB call on my +gcc-based system.</b> +<p>We believe there are some severe bugs in the implementation of exceptions +for some gcc compilers. Exceptions require some interaction between +compiler, assembler, runtime libraries, and we're not sure exactly what +is at fault, but one failing combination is gcc 2.7.2.3 running on SuSE +Linux 6.0. The problem on this system can be seen with a rather simple +test case of an exception thrown from a shared library and caught in the +main program. +<p>A variation of this problem seems to occur on AIX, although we believe it +does not necessarily involve shared libraries on that platform. +<p>If you see a trap that occurs when an exception might be thrown by the DB +runtime, we suggest that you use static libraries instead of dynamic +(shared) libraries. See the documentation for configuration. If this +doesn't work, and you have a choice of compilers, try using a more recent +gcc or a non-gcc based compiler to build Berkeley DB. +<p>Finally, you can disable the use of exceptions in the C++ runtime for +Berkeley DB by using the <a href="../../api_c/db_create.html#DB_CXX_NO_EXCEPTIONS">DB_CXX_NO_EXCEPTIONS</a> flag with +<a href="../../api_c/env_create.html">db_env_create</a> or <a href="../../api_c/db_create.html">db_create</a>. When this flag is on, all +C++ methods fail by returning an error code rather than throwing an +exception. +<hr size=1 noshade> +<p><li><b>I get unexpected results and database corruption when running +threaded programs.</b> +<p><b>I get error messages that mutex (e.g., pthread_mutex_XXX or +mutex_XXX) functions are undefined when linking applications with Berkeley DB.</b> +<p>On some architectures, the Berkeley DB library uses the ISO POSIX standard +pthreads and UNIX International (UI) threads interfaces for underlying +mutex support, e.g., Solaris and HP-UX. You can specify compilers, +compiler flags or link with the appropriate thread library when loading +your application, to resolve the undefined references: +<p><blockquote><pre>cc ... -lpthread ... +cc ... -lthread ... +xlc_r ... +cc ... -mt ...</pre></blockquote> +<p>See the appropriate architecture-specific Reference Guide pages for more +information. +<p>On systems where more than one type of mutex is available, it may be +necessary for applications to use the same threads package from which +Berkeley DB draws its mutexes, e.g., if Berkeley DB was built to use the POSIX +pthreads mutex calls for mutex support, the application may need to be +written to use the POSIX pthreads interfaces for its threading model. +While this is only conjecture at this time and we know of no systems that +actually have this requirement, it's not unlikely that some exist. +<p>In a few cases, Berkeley DB can be configured to use specific underlying mutex +interfaces. You can use the <a href="../../ref/build_unix/conf.html#--enable-posixmutexes">--enable-posixmutexes</a> and +<a href="../../ref/build_unix/conf.html#--enable-uimutexes">--enable-uimutexes</a> configuration options to specify the POSIX and Unix +International (UI) threads packages. This should not, however, be +necessary in most cases. +<p>In some cases, it is vitally important to make sure that you load +the correct library. For example, on Solaris systems, there are POSIX +pthread interfaces in the C library, and so applications can link Berkeley DB +using only C library and not see any undefined symbols. However, the C +library POSIX pthread mutex support is insufficient for Berkeley DB and Berkeley DB +cannot detect that fact. Similar errors can arise when applications +(e.g., tclsh) use dlopen to dynamically load Berkeley DB as a library. +<p>If you are seeing problems in this area after you've confirmed that you're +linking with the correct libraries, there are two other things you can +try. First, if your platform supports inter-library dependencies, we +recommend that you change the Berkeley DB Makefile to specify the appropriate +threads library when creating the Berkeley DB dynamic library, as an +inter-library dependency. Second, if your application is using dlopen to +dynamically load Berkeley DB, specify the appropriate thread library on the link +line when you load the application itself. +<hr size=1 noshade> +<p><li><b>I get core dumps when running programs that fork children.</b> +<p>Berkeley DB handles should not be shared across process forks, each forked +child should acquire its own Berkeley DB handles. +<hr size=1 noshade> +<p><li><b>I get reports of uninitialized memory reads and writes when +running software analysis tools (e.g., Rational Software Corp.'s Purify +tool).</b> +<p>For performance reasons, Berkeley DB does not write the unused portions of +database pages or fill in unused structure fields. To turn off these +errors when running software analysis tools, build with the +--enable-umrw configuration option. +<hr size=1 noshade> +<p><li><b>Berkeley DB programs or the test suite fail unexpectedly.</b> +<p>The Berkeley DB architecture does not support placing the shared memory regions +on remote filesystems, e.g., the Network File System (NFS) or the Andrew +File System (AFS). For this reason, the shared memory regions (normally +located in the database home directory) must reside on a local filesystem. +See <a href="../../ref/env/region.html">Shared Memory Regions</a> for more +information. +<p>With respect to running the test suite, always check to make sure that +TESTDIR is not on a remote mounted filesystem. +<hr size=1 noshade> +<p><li><b>The <a href="../../utility/db_dump.html">db_dump185</a> utility fails to build.</b> +<p>The <a href="../../utility/db_dump.html">db_dump185</a> utility is the utility that supports conversion +of Berkeley DB 1.85 and earlier databases to current database formats. If +the errors look something like: +<p><blockquote><pre>cc -o db_dump185 db_dump185.o +ld: +Unresolved: +dbopen</pre></blockquote> +<p>it means that the Berkeley DB 1.85 code was not found in the standard +libraries. To build <a href="../../utility/db_dump.html">db_dump185</a>, the Berkeley DB version 1.85 code +must have already been built and installed on the system. If the Berkeley DB +1.85 header file is not found in a standard place, or the library is +not part of the standard libraries used for loading, you will need to +edit your Makefile, and change the lines: +<p><blockquote><pre>DB185INC= +DB185LIB=</pre></blockquote> +<p>So that the system Berkeley DB 1.85 header file and library are found, e.g., +<p><blockquote><pre>DB185INC=/usr/local/include +DB185LIB=-ldb185</pre></blockquote> +</ol> +<table><tr><td><br></td><td width="1%"><a href="../../ref/build_unix/test.html"><img src="../../images/prev.gif" alt="Prev"></a><a href="../../ref/toc.html"><img src="../../images/ref.gif" alt="Ref"></a><a href="../../ref/build_unix/aix.html"><img src="../../images/next.gif" alt="Next"></a> +</td></tr></table> +<p><font size=1><a href="http://www.sleepycat.com">Copyright Sleepycat Software</a></font> +</body> +</html> |