1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
|
<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8" />
<title>Solaris</title>
<link rel="stylesheet" href="gettingStarted.css" type="text/css" />
<meta name="generator" content="DocBook XSL Stylesheets V1.73.2" />
<link rel="start" href="index.html" title="Berkeley DB Installation and Build Guide" />
<link rel="up" href="build_unix.html" title="Chapter 7. Building Berkeley DB for UNIX/POSIX" />
<link rel="prev" href="build_unix_sco.html" title="SCO" />
<link rel="next" href="build_unix_sunos.html" title="SunOS" />
</head>
<body>
<div xmlns="" class="navheader">
<div class="libver">
<p>Library Version 11.2.5.3</p>
</div>
<table width="100%" summary="Navigation header">
<tr>
<th colspan="3" align="center">Solaris</th>
</tr>
<tr>
<td width="20%" align="left"><a accesskey="p" href="build_unix_sco.html">Prev</a> </td>
<th width="60%" align="center">Chapter 7.
Building Berkeley DB for UNIX/POSIX
</th>
<td width="20%" align="right"> <a accesskey="n" href="build_unix_sunos.html">Next</a></td>
</tr>
</table>
<hr />
</div>
<div class="sect1" lang="en" xml:lang="en">
<div class="titlepage">
<div>
<div>
<h2 class="title" style="clear: both"><a id="build_unix_solaris"></a>Solaris</h2>
</div>
</div>
</div>
<div class="orderedlist">
<ol type="1">
<li>
<span class="bold">
<strong>I can't compile and run multithreaded applications.</strong>
</span>
<p>Special compile-time flags and additional libraries are required when
compiling threaded applications on Solaris. If you are compiling a
threaded application, you must compile with the D_REENTRANT flag and link
with the libpthread.a or libthread.a libraries:</p>
<pre class="programlisting">cc -mt ...
cc -D_REENTRANT ... -lthread
cc -D_REENTRANT ... -lpthread</pre>
<p>The Berkeley DB library will automatically build with the correct options.</p>
</li>
<li>
<span class="bold">
<strong>I've installed gcc on my Solaris system, but configuration
fails because the compiler doesn't work.</strong>
</span>
<p>On some versions of Solaris, there is a cc executable in the user's path,
but all it does is display an error message and fail:</p>
<pre class="programlisting">% which cc
/usr/ucb/cc
% cc
/usr/ucb/cc: language optional software package not installed</pre>
<p>Because Berkeley DB always uses the native compiler in preference to gcc, this
is a fatal error. If the error message you are seeing is the following,
then this may be the problem:</p>
<pre class="programlisting">checking whether the C compiler (cc -O) works... no
configure: error: installation or configuration problem: C compiler
cannot create executables.</pre>
<p>The simplest workaround is to set your CC environment variable to the
system compiler and reconfigure; for example:</p>
<pre class="programlisting">env CC=gcc ../dist/configure</pre>
<p>If you are using the --configure-cxx option, you may also want to specify
a C++ compiler, for example the following:</p>
<pre class="programlisting">env CC=gcc CCC=g++ ../dist/configure</pre>
</li>
<li>
<span class="bold">
<strong>I see the error
"libc internal error: _rmutex_unlock: rmutex not held", followed by a core
dump when running threaded or JAVA programs.</strong>
</span>
<p>This is a known bug in Solaris 2.5 and it is fixed by Sun patch 103187-25.</p>
</li>
<li>
<span class="bold">
<strong>I see error reports of nonexistent files, corrupted metadata
pages and core dumps.</strong>
</span>
<p>Solaris 7 contains a bug in the threading libraries (-lpthread,
-lthread), which causes the wrong version of the pwrite routine to be
linked into the application if the thread library is linked in after
the C library. The result will be that the pwrite function is called
rather than the pwrite64. To work around the problem, use an explicit
link order when creating your application.</p>
<p>Sun Microsystems is tracking this problem with Bug Id's 4291109 and 4267207,
and patch 106980-09 to Solaris 7 fixes the problem:</p>
<pre class="programlisting">Bug Id: 4291109
Duplicate of: 4267207
Category: library
Subcategory: libthread
State: closed
Synopsis: pwrite64 mapped to pwrite
Description:
When libthread is linked after libc, there is a table of functions in
libthread that gets "wired into" libc via _libc_threads_interface().
The table in libthread is wrong in both Solaris 7 and on28_35 for the
TI_PWRITE64 row (see near the end).</pre>
</li>
<li>
<span class="bold">
<strong>I see corrupted databases when doing hot backups or creating
a hot failover archive.</strong>
</span>
<p>The Solaris cp utility is implemented using the mmap system call, and
so writes are not blocked when it reads database pages. See
<a href="../programmer_reference/transapp_reclimit.html" class="olink">Berkeley DB recoverability</a>
for more information.</p>
</li>
<li>
<span class="bold">
<strong>Performance is slow and the application is doing a lot of I/O
to the disk on which the database environment's files are stored.</strong>
</span>
<p>By default, Solaris periodically flushes dirty blocks from memory-mapped
files to the backing filesystem. This includes the Berkeley DB database
environment's shared memory regions and can affect Berkeley DB performance.
Workarounds include creating the shared regions in system shared memory
(<a href="../api_reference/C/envopen.html#envopen_DB_SYSTEM_MEM" class="olink">DB_SYSTEM_MEM</a>) or application private memory
(<a href="../api_reference/C/envopen.html#envopen_DB_PRIVATE" class="olink">DB_PRIVATE</a>), or configuring Solaris to not flush memory-mapped
pages. For more information, see the "Solaris Tunable Parameters
Reference Manual: fsflush and Related Tunables".</p>
</li>
<li>
<span class="bold">
<strong>I see errors about "open64" when building Berkeley DB applications.</strong>
</span>
<p>System include files (most commonly fcntl.h) in some releases of AIX
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:
</p>
<div class="orderedlist">
<ol type="a">
<li>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.</li>
<li>Before building Berkeley DB, modify the generated include file db.h to itself
include the problematical system include files.</li>
<li>Turn off Berkeley DB large-file support by specifying the
<a class="link" href="build_unix_conf.html#build_unix_conf.--disable-largefile">--disable-largefile</a> configuration option and rebuilding.</li>
</ol>
</div>
</li>
</ol>
</div>
</div>
<div class="navfooter">
<hr />
<table width="100%" summary="Navigation footer">
<tr>
<td width="40%" align="left"><a accesskey="p" href="build_unix_sco.html">Prev</a> </td>
<td width="20%" align="center">
<a accesskey="u" href="build_unix.html">Up</a>
</td>
<td width="40%" align="right"> <a accesskey="n" href="build_unix_sunos.html">Next</a></td>
</tr>
<tr>
<td width="40%" align="left" valign="top">SCO </td>
<td width="20%" align="center">
<a accesskey="h" href="index.html">Home</a>
</td>
<td width="40%" align="right" valign="top"> SunOS</td>
</tr>
</table>
</div>
</body>
</html>
|
