1<!--$Id: notes.so,v 10.54 2005/06/16 17:04:04 bostic Exp $--> 2<!--Copyright (c) 1997,2008 Oracle. All rights reserved.--> 3<!--See the file LICENSE for redistribution information.--> 4<html> 5<head> 6<title>Berkeley DB Reference Guide: Architecture independent FAQ</title> 7<meta name="description" content="Berkeley DB: An embedded database programmatic toolkit."> 8<meta name="keywords" content="embedded,database,programmatic,toolkit,btree,hash,hashing,transaction,transactions,locking,logging,access method,access methods,Java,C,C++"> 9</head> 10<body bgcolor=white> 11<a name="2"><!--meow--></a><a name="3"><!--meow--></a> 12<table width="100%"><tr valign=top> 13<td><b><dl><dt>Berkeley DB Reference Guide:<dd>Building Berkeley DB for UNIX/POSIX systems</dl></b></td> 14<td align=right><a href="/build_unix/test.html"><img src="/images/prev.gif" alt="Prev"></a><a href="/toc.html"><img src="/images/ref.gif" alt="Ref"></a><a href="/build_unix/aix.html"><img src="/images/next.gif" alt="Next"></a> 15</td></tr></table> 16<p align=center><b>Architecture independent FAQ</b></p> 17<ol> 18<p><li><b>I have gcc installed, but configure fails to find it.</b> 19<p>Berkeley DB defaults to using the native C compiler if none is specified. 20That is usually "cc", but some platforms require a different compiler 21to build multithreaded code. To configure Berkeley DB to build with gcc, run 22configure as follows:</p> 23<blockquote><pre>env CC=gcc /dist/configure ...</pre></blockquote> 24<hr size=1 noshade> 25<p><li><b>When compiling with gcc, I get unreferenced symbols; for example 26the following: 27<blockquote><pre>symbol __muldi3: referenced symbol not found 28symbol __cmpdi2: referenced symbol not found</pre></blockquote></b> 29<p>Berkeley DB often uses 64-bit integral types on systems supporting large 30files, and gcc performs operations on those types by calling library 31functions. These unreferenced symbol errors are usually caused by 32linking an application by calling "ld" rather than by calling "gcc": 33gcc will link in libgcc.a and will resolve the symbols. If that does 34not help, another possible workaround is to reconfigure Berkeley DB using the 35<a href="/ref/build_unix/conf.html#--disable-largefile">--disable-largefile</a> configuration option and then rebuild.</p> 36<hr size=1 noshade> 37<p><li><b>My C++ program traps during a failure in a DB call on my 38gcc-based system.</b> 39<p>We believe there are some severe bugs in the implementation of 40exceptions for some gcc compilers. Exceptions require some interaction 41between compiler, assembler, and runtime libraries. We're not sure 42exactly what is at fault, but one failing combination is gcc 2.7.2.3 43running on SuSE Linux 6.0. The problem on this system can be seen with 44a rather simple test case of an exception thrown from a shared library 45and caught in the main program.</p> 46<p>A variation of this problem seems to occur on AIX, although we believe it 47does not necessarily involve shared libraries on that platform.</p> 48<p>If you see a trap that occurs when an exception might be thrown by the 49Berkeley DB runtime, we suggest that you use static libraries instead of 50shared libraries. See the documentation for configuration. If this 51doesn't work and you have a choice of compilers, try using a more recent 52gcc- or a non-gcc based compiler to build Berkeley DB.</p> 53<p>Finally, you can disable the use of exceptions in the C++ runtime for 54Berkeley DB by using the <a href="/api_cxx/env_class.html#DB_CXX_NO_EXCEPTIONS">DB_CXX_NO_EXCEPTIONS</a> flag with the 55<a href="/api_cxx/env_class.html">DbEnv</a> or <a href="/api_cxx/db_class.html">Db</a> constructors. When this flag is on, 56all C++ methods fail by returning an error code rather than throwing an 57exception.</p> 58<hr size=1 noshade> 59<p><li><b>I get unexpected results and database corruption when running 60threaded programs.</b> 61<p><b>I get error messages that mutex (for example, pthread_mutex_XXX or 62mutex_XXX) functions are undefined when linking applications with Berkeley DB.</b></p> 63<p>On some architectures, the Berkeley DB library uses the ISO POSIX standard 64pthreads and UNIX International (UI) threads interfaces for underlying 65mutex support; for example, Solaris and HP-UX. You can specify 66compilers or compiler flags, or link with the appropriate thread library 67when loading your application to resolve the undefined references:</p> 68<blockquote><pre>cc ... -lpthread ... 69cc ... -lthread ... 70xlc_r ... 71cc ... -mt ...</pre></blockquote> 72<p>See the appropriate architecture-specific Reference Guide pages for more 73information.</p> 74<p>On systems where more than one type of mutex is available, it may be 75necessary for applications to use the same threads package from which 76Berkeley DB draws its mutexes. For example, if Berkeley DB was built to use the 77POSIX pthreads mutex calls for mutex support, the application may need 78to be written to use the POSIX pthreads interfaces for its threading 79model. This is only conjecture at this time, and although we know of 80no systems that actually have this requirement, it's not unlikely that 81some exist.</p> 82<p>In a few cases, Berkeley DB can be configured to use specific underlying mutex 83interfaces. You can use the <a href="/ref/build_unix/conf.html#--enable-posixmutexes">--enable-posixmutexes</a> and 84<a href="/ref/build_unix/conf.html#--enable-uimutexes">--enable-uimutexes</a> configuration options to specify the POSIX and Unix 85International (UI) threads packages. This should not, however, be 86necessary in most cases.</p> 87<p>In some cases, it is vitally important to make sure that you load the 88correct library. For example, on Solaris systems, there are POSIX 89pthread interfaces in the C library, so applications can link Berkeley DB 90using only C library and not see any undefined symbols. However, the 91C library POSIX pthread mutex support is insufficient for Berkeley DB, and 92Berkeley DB cannot detect that fact. Similar errors can arise when 93applications (for example, tclsh) use dlopen to dynamically load Berkeley DB 94as a library.</p> 95<p>If you are seeing problems in this area after you confirm that you're 96linking with the correct libraries, there are two other things you can 97try. First, if your platform supports interlibrary dependencies, we 98recommend that you change the Berkeley DB Makefile to specify the appropriate 99threads library when creating the Berkeley DB shared library, as an 100interlibrary dependency. Second, if your application is using dlopen 101to dynamically load Berkeley DB, specify the appropriate thread library on 102the link line when you load the application itself.</p> 103<hr size=1 noshade> 104<p><li><b>I get core dumps when running programs that fork children.</b> 105<p>Berkeley DB handles should not be shared across process forks, each forked 106child should acquire its own Berkeley DB handles.</p> 107<hr size=1 noshade> 108<p><li><b>I get reports of uninitialized memory reads and writes when 109running software analysis tools (for example, Rational Software Corp.'s 110Purify tool).</b> 111<p>For performance reasons, Berkeley DB does not write the unused portions of 112database pages or fill in unused structure fields. To turn off these 113errors when running software analysis tools, build with the 114<a href="/ref/build_unix/conf.html#--enable-umrw">--enable-umrw</a> 115configuration option.</p> 116<hr size=1 noshade> 117<p><li><b>Berkeley DB programs or the test suite fail unexpectedly.</b> 118<p>The Berkeley DB architecture does not support placing the shared memory 119regions on remote filesystems -- for example, the Network File System 120(NFS) or the Andrew File System (AFS). For this reason, the shared 121memory regions (normally located in the database home directory) must 122reside on a local filesystem. See <a href="/ref/env/region.html">Shared Memory Regions</a> for more information.</p> 123<p>With respect to running the test suite, always check to make sure that 124TESTDIR is not on a remote mounted filesystem.</p> 125<hr size=1 noshade> 126<p><li><b>The <a href="/utility/db_dump.html">db_dump185</a> utility fails to build.</b> 127<p>The <a href="/utility/db_dump.html">db_dump185</a> utility is the utility that supports the 128conversion of Berkeley DB 1.85 and earlier databases to current database 129formats. If the build errors look something like the following, it 130means the db.h include file being loaded is not a Berkeley DB 1.85 version 131include file:</p> 132<blockquote><pre>db_dump185.c: In function `main': 133db_dump185.c:210: warning: assignment makes pointer from integer without a cast 134db_dump185.c:212: warning: assignment makes pointer from integer without a cast 135db_dump185.c:227: structure has no member named `seq' 136db_dump185.c:227: `R_NEXT' undeclared (first use in this function)</pre></blockquote> 137<p>If the build errors look something like the following, it means that 138the Berkeley DB 1.85 code was not found in the standard libraries:</p> 139<blockquote><pre>cc -o db_dump185 db_dump185.o 140ld: 141Unresolved: 142dbopen</pre></blockquote> 143<p>To build <a href="/utility/db_dump.html">db_dump185</a>, the Berkeley DB version 1.85 code must already 144been built and available on the system. If the Berkeley DB 1.85 header file 145is not found in a standard place, or if the library is not part of the 146standard libraries used for loading, you will need to edit your 147Makefile, and change the following lines:</p> 148<blockquote><pre>DB185INC= 149DB185LIB=</pre></blockquote> 150<p>So that the system Berkeley DB 1.85 header file and library are found; for 151example:</p> 152<blockquote><pre>DB185INC=/usr/local/include 153DB185LIB=-ldb185</pre></blockquote> 154</ol> 155<table width="100%"><tr><td><br></td><td align=right><a href="/build_unix/test.html"><img src="/images/prev.gif" alt="Prev"></a><a href="/toc.html"><img src="/images/ref.gif" alt="Ref"></a><a href="/build_unix/aix.html"><img src="/images/next.gif" alt="Next"></a> 156</td></tr></table> 157<p><font size=1>Copyright (c) 1996,2008 Oracle. All rights reserved.</font> 158</body> 159</html> 160