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
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
|
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd">
<html>
<!-- Created by GNU Texinfo 6.7, http://www.gnu.org/software/texinfo/ -->
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
<title>Installation Problems (GNU Octave (version 6.2.0))</title>
<meta name="description" content="Installation Problems (GNU Octave (version 6.2.0))">
<meta name="keywords" content="Installation Problems (GNU Octave (version 6.2.0))">
<meta name="resource-type" content="document">
<meta name="distribution" content="global">
<meta name="Generator" content="makeinfo">
<link href="index.html" rel="start" title="Top">
<link href="Concept-Index.html" rel="index" title="Concept Index">
<link href="index.html#SEC_Contents" rel="contents" title="Table of Contents">
<link href="Installation.html" rel="up" title="Installation">
<link href="Grammar-and-Parser.html" rel="next" title="Grammar and Parser">
<link href="Compiling-Octave-with-64_002dbit-Indexing.html" rel="prev" title="Compiling Octave with 64-bit Indexing">
<style type="text/css">
<!--
a.summary-letter {text-decoration: none}
blockquote.indentedblock {margin-right: 0em}
div.display {margin-left: 3.2em}
div.example {margin-left: 3.2em}
div.lisp {margin-left: 3.2em}
kbd {font-style: oblique}
pre.display {font-family: inherit}
pre.format {font-family: inherit}
pre.menu-comment {font-family: serif}
pre.menu-preformatted {font-family: serif}
span.nolinebreak {white-space: nowrap}
span.roman {font-family: initial; font-weight: normal}
span.sansserif {font-family: sans-serif; font-weight: normal}
ul.no-bullet {list-style: none}
-->
</style>
<link rel="stylesheet" type="text/css" href="octave.css">
</head>
<body lang="en">
<span id="Installation-Problems"></span><div class="header">
<p>
Previous: <a href="Compiling-Octave-with-64_002dbit-Indexing.html" accesskey="p" rel="prev">Compiling Octave with 64-bit Indexing</a>, Up: <a href="Installation.html" accesskey="u" rel="up">Installation</a> [<a href="index.html#SEC_Contents" title="Table of contents" rel="contents">Contents</a>][<a href="Concept-Index.html" title="Index" rel="index">Index</a>]</p>
</div>
<hr>
<span id="Installation-Problems-1"></span><h3 class="section">E.4 Installation Problems</h3>
<p>This section contains a list of problems (and some apparent problems
that don’t really mean anything is wrong) that may show up during
installation of Octave.
</p>
<ul>
<li> On some SCO systems, <code>info</code> fails to compile if
<code><span class="nolinebreak">HAVE_TERMIOS_H</span></code><!-- /@w --> is defined in <samp>config.h</samp>. Simply
removing the definition from <samp>info/config.h</samp> should allow it to
compile.
</li><li> If <code>configure</code> finds <code>dlopen</code>, <code>dlsym</code>, <code>dlclose</code>,
and <code>dlerror</code>, but not the header file <samp>dlfcn.h</samp>, you need to
find the source for the header file and install it in the directory
<samp>usr/include</samp>. This is reportedly a problem with Slackware 3.1.
For Linux/GNU systems, the source for <samp>dlfcn.h</samp> is in the
<code>ldso</code> package.
</li><li> Building <samp>.oct</samp> files doesn’t work.
<p>You should probably have a shared version of <code>libstdc++</code>. A patch
is needed to build shared versions of version 2.7.2 of <code>libstdc++</code>
on the HP-PA architecture. You can find the patch at
<a href="ftp://ftp.cygnus.com/pub/g++/libg++-2.7.2-hppa-gcc-fix">ftp://ftp.cygnus.com/pub/g++/libg++-2.7.2-hppa-gcc-fix</a>.
</p>
</li><li> On some DEC alpha systems there may be a problem with the <code>libdxml</code>
library, resulting in floating point errors and/or segmentation faults
in the linear algebra routines called by Octave. If you encounter such
problems, then you should modify the configure script so that
<code><span class="nolinebreak">SPECIAL_MATH_LIB</span></code><!-- /@w --> is not set to <code>-ldxml</code>.
</li><li> On FreeBSD systems Octave may hang while initializing some internal
constants. The fix appears to be to use
<div class="example">
<pre class="example">options GPL_MATH_EMULATE
</pre></div>
<p>rather than
</p>
<div class="example">
<pre class="example">options MATH_EMULATE
</pre></div>
<p>in the kernel configuration files (typically found in the directory
<samp>/sys/i386/conf</samp>). After making this change, you’ll need to rebuild
the kernel, install it, and reboot.
</p>
</li><li> If you encounter errors like
<div class="example">
<pre class="example">passing `void (*)()' as argument 2 of
`octave_set_signal_handler(int, void (*)(int))'
</pre></div>
<p>or
</p>
<div class="example">
<pre class="example">warning: ANSI C++ prohibits conversion from `(int)'
to `(…)'
</pre></div>
<p>while compiling <samp>sighandlers.cc</samp>, you may need to edit some files
in the <code>gcc</code> include subdirectory to add proper prototypes for
functions there. For example, Ultrix 4.2 needs proper declarations for
the <code>signal</code> function and the <code><span class="nolinebreak">SIG_IGN</span></code><!-- /@w --> macro in the file
<samp>signal.h</samp>.
</p>
<p>On some systems the <code><span class="nolinebreak">SIG_IGN</span></code><!-- /@w --> macro is defined to be something
like this:
</p>
<div class="example">
<pre class="example">#define SIG_IGN (void (*)())1
</pre></div>
<p>when it should really be something like:
</p>
<div class="example">
<pre class="example">#define SIG_IGN (void (*)(int))1
</pre></div>
<p>to match the prototype declaration for the <code>signal</code> function. This
change should also be made for the <code><span class="nolinebreak">SIG_DFL</span></code><!-- /@w --> and
<code><span class="nolinebreak">SIG_ERR</span></code><!-- /@w --> symbols. It may be necessary to change the
definitions in <samp>sys/signal.h</samp> as well.
</p>
<p>The <code>gcc</code> <code>fixincludes</code> and <code>fixproto</code> scripts should
probably fix these problems when <code>gcc</code> installs its modified set of
header files, but I don’t think that’s been done yet.
</p>
<p><strong>You should not change the files in <samp>/usr/include</samp></strong>. You
can find the <code>gcc</code> include directory tree by running the command
</p>
<div class="example">
<pre class="example">gcc -print-libgcc-file-name
</pre></div>
<p>The directory of <code>gcc</code> include files normally begins in the same
directory that contains the file <samp>libgcc.a</samp>.
</p>
</li><li> Some of the Fortran subroutines may fail to compile with older versions
of the Sun Fortran compiler. If you get errors like
<div class="example">
<pre class="example">zgemm.f:
zgemm:
warning: unexpected parent of complex expression subtree
zgemm.f, line 245: warning: unexpected parent of complex
expression subtree
warning: unexpected parent of complex expression subtree
zgemm.f, line 304: warning: unexpected parent of complex
expression subtree
warning: unexpected parent of complex expression subtree
zgemm.f, line 327: warning: unexpected parent of complex
expression subtree
pcc_binval: missing IR_CONV in complex op
make[2]: *** [zgemm.o] Error 1
</pre></div>
<p>when compiling the Fortran subroutines in the <samp>liboctave/external</samp>
subdirectory, you should either upgrade your compiler or try compiling
with optimization turned off.
</p>
</li><li> On NeXT systems, if you get errors like this:
<div class="example">
<pre class="example">/usr/tmp/cc007458.s:unknown:Undefined local
symbol LBB7656
/usr/tmp/cc007458.s:unknown:Undefined local
symbol LBE7656
</pre></div>
<p>when compiling <samp>Array.cc</samp> and <samp>Matrix.cc</samp>, try recompiling
these files without <samp>-g</samp>.
</p>
</li><li> Some people have reported that calls to system() and the pager do not
work on SunOS systems. This is apparently due to having
<code><span class="nolinebreak">G_HAVE_SYS_WAIT</span></code><!-- /@w --> defined to be 0 instead of 1 when compiling
<code>libg++</code>.
</li><li> On systems where the reference <small>BLAS</small> library is used the following
matrix-by-vector multiplication incorrectly handles NaN values of the
form <code>NaN * 0</code>.
<div class="example">
<pre class="example">[NaN, 1; 0, 0] * [0; 1]
⇒
[ 1
0 ]
correct result ⇒
[ NaN
0 ]
</pre></div>
<p>Install a different <small>BLAS</small> library such as OpenBLAS or ATLAS to correct
this issue.
</p>
</li><li> On NeXT systems, linking to <samp>libsys_s.a</samp> may fail to resolve the
following functions
<div class="example">
<pre class="example">_tcgetattr
_tcsetattr
_tcflow
</pre></div>
<p>which are part of <samp>libposix.a</samp>. Unfortunately, linking Octave with
<samp>-posix</samp> results in the following undefined symbols.
</p>
<div class="example">
<pre class="example">.destructors_used
.constructors_used
_objc_msgSend
_NXGetDefaultValue
_NXRegisterDefaults
.objc_class_name_NXStringTable
.objc_class_name_NXBundle
</pre></div>
<p>One kluge around this problem is to extract <samp>termios.o</samp> from
<samp>libposix.a</samp>, put it in Octave’s <samp>src</samp> directory, and add it
to the list of files to link together in the makefile. Suggestions for
better ways to solve this problem are welcome!
</p>
</li><li> If Octave crashes immediately with a floating point exception, it is
likely that it is failing to initialize the IEEE floating point values
for infinity and NaN.
<p>If your system actually does support IEEE arithmetic, you should be able
to fix this problem by modifying the function <code>octave_ieee_init</code> in
the file <samp>lo-ieee.cc</samp> to correctly initialize Octave’s internal
infinity and NaN variables.
</p>
<p>If your system does not support IEEE arithmetic but Octave’s configure
script incorrectly determined that it does, you can work around the
problem by editing the file <samp>config.h</samp> to not define
<code><span class="nolinebreak">HAVE_ISINF</span></code><!-- /@w -->, <code><span class="nolinebreak">HAVE_FINITE</span></code><!-- /@w -->, and
<code><span class="nolinebreak">HAVE_ISNAN</span></code><!-- /@w -->.
</p>
<p>In any case, please report this as a bug since it might be possible to
modify Octave’s configuration script to automatically determine the
proper thing to do.
</p>
</li><li> If Octave is unable to find a header file because it is installed in a
location that is not normally searched by the compiler, you can add the
directory to the include search path by specifying (for example)
<code>CPPFLAGS=-I/some/nonstandard/directory</code> as an argument to
<code>configure</code>. Other variables that can be specified this way are
<code>CFLAGS</code>, <code>CXXFLAGS</code>, <code>FFLAGS</code>, and <code>LDFLAGS</code>. Passing
them as options to the configure script also records them in the
<samp>config.status</samp> file. By default, <code>CPPFLAGS</code> and <code>LDFLAGS</code>
are empty, <code>CFLAGS</code> and <code>CXXFLAGS</code> are set to <code>"-g -O2"</code> and
<code>FFLAGS</code> is set to <code>"-O"</code>.
</li></ul>
<hr>
<div class="header">
<p>
Previous: <a href="Compiling-Octave-with-64_002dbit-Indexing.html" accesskey="p" rel="prev">Compiling Octave with 64-bit Indexing</a>, Up: <a href="Installation.html" accesskey="u" rel="up">Installation</a> [<a href="index.html#SEC_Contents" title="Table of contents" rel="contents">Contents</a>][<a href="Concept-Index.html" title="Index" rel="index">Index</a>]</p>
</div>
</body>
</html>
|
