<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd"> <html> <!-- Created by GNU Texinfo 6.5, http://www.gnu.org/software/texinfo/ --> <head> <meta http-equiv="Content-Type" content="text/html; charset=utf-8"> <title>Installation Problems (GNU Octave (version 5.1.0))</title> <meta name="description" content="Installation Problems (GNU Octave (version 5.1.0))"> <meta name="keywords" content="Installation Problems (GNU Octave (version 5.1.0))"> <meta name="resource-type" content="document"> <meta name="distribution" content="global"> <meta name="Generator" content="makeinfo"> <link href="index.html#Top" rel="start" title="Top"> <link href="Concept-Index.html#Concept-Index" rel="index" title="Concept Index"> <link href="index.html#SEC_Contents" rel="contents" title="Table of Contents"> <link href="Installation.html#Installation" rel="up" title="Installation"> <link href="Grammar-and-Parser.html#Grammar-and-Parser" rel="next" title="Grammar and Parser"> <link href="Compiling-Octave-with-64_002dbit-Indexing.html#Compiling-Octave-with-64_002dbit-Indexing" rel="prev" title="Compiling Octave with 64-bit Indexing"> <style type="text/css"> <!-- a.summary-letter {text-decoration: none} blockquote.indentedblock {margin-right: 0em} blockquote.smallindentedblock {margin-right: 0em; font-size: smaller} blockquote.smallquotation {font-size: smaller} div.display {margin-left: 3.2em} div.example {margin-left: 3.2em} div.lisp {margin-left: 3.2em} div.smalldisplay {margin-left: 3.2em} div.smallexample {margin-left: 3.2em} div.smalllisp {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} pre.smalldisplay {font-family: inherit; font-size: smaller} pre.smallexample {font-size: smaller} pre.smallformat {font-family: inherit; font-size: smaller} pre.smalllisp {font-size: smaller} 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"> <a name="Installation-Problems"></a> <div class="header"> <p> Previous: <a href="Compiling-Octave-with-64_002dbit-Indexing.html#Compiling-Octave-with-64_002dbit-Indexing" accesskey="p" rel="prev">Compiling Octave with 64-bit Indexing</a>, Up: <a href="Installation.html#Installation" 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#Concept-Index" title="Index" rel="index">Index</a>]</p> </div> <hr> <a name="Installation-Problems-1"></a> <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#Compiling-Octave-with-64_002dbit-Indexing" accesskey="p" rel="prev">Compiling Octave with 64-bit Indexing</a>, Up: <a href="Installation.html#Installation" 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#Concept-Index" title="Index" rel="index">Index</a>]</p> </div> </body> </html>