File: Installation-Problems.html

package info (click to toggle)
octave3.2 3.2.4-8
  • links: PTS, VCS
  • area: main
  • in suites: squeeze
  • size: 62,936 kB
  • ctags: 37,353
  • sloc: cpp: 219,497; fortran: 116,336; ansic: 10,264; sh: 5,508; makefile: 4,245; lex: 3,573; yacc: 3,062; objc: 2,042; lisp: 1,692; awk: 860; perl: 844
file content (225 lines) | stat: -rw-r--r-- 11,187 bytes parent folder | download
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
<html lang="en">
<head>
<title>Installation Problems - Untitled</title>
<meta http-equiv="Content-Type" content="text/html">
<meta name="description" content="Untitled">
<meta name="generator" content="makeinfo 4.11">
<link title="Top" rel="start" href="index.html#Top">
<link rel="up" href="Installation.html#Installation" title="Installation">
<link href="http://www.gnu.org/software/texinfo/" rel="generator-home" title="Texinfo Homepage">
<meta http-equiv="Content-Style-Type" content="text/css">
<style type="text/css"><!--
  pre.display { font-family:inherit }
  pre.format  { font-family:inherit }
  pre.smalldisplay { font-family:inherit; font-size:smaller }
  pre.smallformat  { font-family:inherit; font-size:smaller }
  pre.smallexample { font-size:smaller }
  pre.smalllisp    { font-size:smaller }
  span.sc    { font-variant:small-caps }
  span.roman { font-family:serif; font-weight:normal; } 
  span.sansserif { font-family:sans-serif; font-weight:normal; } 
--></style>
</head>
<body>
<div class="node">
<p>
<a name="Installation-Problems"></a>
Up:&nbsp;<a rel="up" accesskey="u" href="Installation.html#Installation">Installation</a>
<hr>
</div>

<h3 class="appendixsec">F.1 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.

     <ul>
<li>On some SCO systems, <code>info</code> fails to compile if
<code>HAVE_TERMIOS_H</code><!-- /@w --> is defined in <samp><span class="file">config.h</span></samp>.  Simply removing
the definition from <samp><span class="file">info/config.h</span></samp> should allow it to compile.

     <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><span class="file">dlfcn.h</span></samp>, you need to
find the source for the header file and install it in the directory
<samp><span class="file">usr/include</span></samp>.  This is reportedly a problem with Slackware 3.1. 
For Linux/GNU systems, the source for <samp><span class="file">dlfcn.h</span></samp> is in the
<code>ldso</code> package.

     <li>Building <samp><span class="file">.oct</span></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>.

     <li>On some 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>SPECIAL_MATH_LIB</code><!-- /@w --> is not set to <code>-ldxml</code>.

     <li>On FreeBSD systems Octave may hang while initializing some internal
constants.  The fix appears to be to use

     <pre class="example">          options      GPL_MATH_EMULATE
</pre>
     <p class="noindent">rather than

     <pre class="example">          options      MATH_EMULATE
</pre>
     <p class="noindent">in the kernel configuration files (typically found in the directory
<samp><span class="file">/sys/i386/conf</span></samp>.  After making this change, you'll need to rebuild
the kernel, install it, and reboot.

     <li>If you encounter errors like

     <pre class="example">          passing `void (*)()' as argument 2 of
            `octave_set_signal_handler(int, void (*)(int))'
</pre>
     <p class="noindent">or

     <pre class="example">          warning: ANSI C++ prohibits conversion from `(int)'
                   to `(...)'
</pre>
     <p class="noindent">while compiling <samp><span class="file">sighandlers.cc</span></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>SIG_IGN</code><!-- /@w --> macro in the file
<samp><span class="file">signal.h</span></samp>.

     <p>On some systems the <code>SIG_IGN</code><!-- /@w --> macro is defined to be something like
this:

     <pre class="example">          #define  SIG_IGN  (void (*)())1
</pre>
     <p class="noindent">when it should really be something like:

     <pre class="example">          #define  SIG_IGN  (void (*)(int))1
</pre>
     <p class="noindent">to match the prototype declaration for the <code>signal</code> function.  This
change should also be made for the <code>SIG_DFL</code><!-- /@w --> and <code>SIG_ERR</code><!-- /@w -->
symbols.  It may be necessary to change the definitions in
<samp><span class="file">sys/signal.h</span></samp> as well.

     <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><strong>You should not change the files in </strong><samp><span class="file">/usr/include</span></samp>.  You
can find the <code>gcc</code> include directory tree by running the command

     <pre class="example">          gcc -print-libgcc-file-name
</pre>
     <p class="noindent">The directory of <code>gcc</code> include files normally begins in the same directory
that contains the file <samp><span class="file">libgcc.a</span></samp>.

     <li>Some of the Fortran subroutines may fail to compile with older versions
of the Sun Fortran compiler.  If you get errors like

     <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>
     <p class="noindent">when compiling the Fortran subroutines in the <samp><span class="file">libcruft</span></samp>
subdirectory, you should either upgrade your compiler or try compiling
with optimization turned off.

     <li>On NeXT systems, if you get errors like this:

     <pre class="example">          /usr/tmp/cc007458.s:unknown:Undefined local
                symbol LBB7656
          /usr/tmp/cc007458.s:unknown:Undefined local
                symbol LBE7656
</pre>
     <p class="noindent">when compiling <samp><span class="file">Array.cc</span></samp> and <samp><span class="file">Matrix.cc</span></samp>, try recompiling
these files without <code>-g</code>.

     <li>Some people have reported that calls to shell_cmd and the pager do not
work on SunOS systems.  This is apparently due to having
<code>G_HAVE_SYS_WAIT</code><!-- /@w --> defined to be 0 instead of 1 when compiling
<code>libg++</code>.

     <li>On NeXT systems, linking to <samp><span class="file">libsys_s.a</span></samp> may fail to resolve the
following functions

     <pre class="example">          _tcgetattr
          _tcsetattr
          _tcflow
</pre>
     <p class="noindent">which are part of <samp><span class="file">libposix.a</span></samp>.  Unfortunately, linking Octave with
<code>-posix</code> results in the following undefined symbols.

     <pre class="example">          .destructors_used
          .constructors_used
          _objc_msgSend
          _NXGetDefaultValue
          _NXRegisterDefaults
          .objc_class_name_NXStringTable
          .objc_class_name_NXBundle
</pre>
     <p>One kluge around this problem is to extract <samp><span class="file">termios.o</span></samp> from
<samp><span class="file">libposix.a</span></samp>, put it in Octave's <samp><span class="file">src</span></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!

     <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><span class="file">lo-ieee.cc</span></samp> to correctly initialize Octave's internal
infinity and NaN variables.

     <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><span class="file">config.h</span></samp> to not define
<code>HAVE_ISINF</code><!-- /@w -->, <code>HAVE_FINITE</code><!-- /@w -->, and <code>HAVE_ISNAN</code><!-- /@w -->.

     <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.

     <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><span class="file">config.status</span></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 -O"</code> and <code>FFLAGS</code> is set to <code>"-O"</code>.

   </ul>

<!-- DO NOT EDIT!  Generated automatically by munge-texi. -->
<!-- Copyright (C) 1996, 1997, 1999, 2001, 2002, 2003, 2005, -->
<!-- 2006, 2007, 2008, 2009 Kurt Hornik -->
<!-- This file is part of Octave. -->
<!-- Octave is free software; you can redistribute it and/or modify it -->
<!-- under the terms of the GNU General Public License as published by the -->
<!-- Free Software Foundation; either version 3 of the License, or (at -->
<!-- your option) any later version. -->
<!-- Octave is distributed in the hope that it will be useful, but WITHOUT -->
<!-- ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or -->
<!-- FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License -->
<!-- for more details. -->
<!-- You should have received a copy of the GNU General Public License -->
<!-- along with Octave; see the file COPYING.  If not, see -->
<!-- <http://www.gnu.org/licenses/>. -->
<!-- Written by Kurt Hornik <Kurt.Hornik@wu-wien.ac.at> on 1996/05/17. -->
<!-- Last updated by KH on 1997/07/31. -->
   </body></html>