安装问题 (GNU Octave(版本11.1.0))

E.4 安装问题 ¶

本节列出了Octave安装过程中可能出现的问题（以及一些表面上的问题，这些表面问题实际上并不表示有任何错误）。

在某些SCO系统上，如果定义了HAVE_TERMIOS_H，则info编译失败。只需从info/config.h中删除该定义，应该就可以正常编译。
如果configure找到了dlopen、dlsym、dlclose和dlerror，但未找到头文件dlfcn.h，则需要找到头文件的源文件并安装到usr/include目录中。据报道，这是Slackware 3.1上的一个问题。对于Linux/GNU系统，dlfcn.h的源代码在ldso软件包中。
构建.oct文件无法正常工作。
你应该拥有一个共享版本的libstdc++。在HP-PA架构上构建2.7.2版本的libstdc++的共享版本需要应用补丁。你可以在以下位置找到该补丁： ftp://ftp.cygnus.com/pub/g++/libg++-2.7.2-hppa-gcc-fix。
在某些DEC alpha系统上，libdxml库可能会出现问题，导致Octave调用的线性代数子程序中出现浮点错误和/或段错误。如果你遇到此类问题，则应修改configure脚本，使SPECIAL_MATH_LIB不被设置为-ldxml。
在FreeBSD系统上，Octave在初始化某些内部常量时可能会挂起。修复方法似乎是使用
```
options      GPL_MATH_EMULATE
```
而不是
```
options      MATH_EMULATE
```
在内核配置文件中（通常在/sys/i386/conf目录中找到）。进行此更改后，你需要重新构建内核、安装它，然后重新启动。
如果你遇到类似以下的错误
```
passing `void (*)()' as argument 2 of
  `octave_set_signal_handler(int, void (*)(int))'
```
或
```
warning: ANSI C++ prohibits conversion from `(int)'
         to `(...)'
```
在编译sighandlers.cc时，你可能需要编辑gccinclude子目录中的某些文件，以添加适当的函数原型。例如，Ultrix 4.2需要为signal函数和signal.h文件中的SIG_IGN宏添加正确的声明。

在某些系统上，SIG_IGN宏的定义可能是这样的：
```
#define  SIG_IGN  (void (*)())1
```
但它实际上应该是这样的：
```
#define  SIG_IGN  (void (*)(int))1
```
以匹配signal函数的原型声明。此更改也应对SIG_DFL和SIG_ERR符号进行。可能还需要修改sys/signal.h中的定义。

gcc的fixincludes和fixproto脚本在gcc安装其修改后的头文件集时，应该能修复这些问题，但我认为这还没有完成。

你不应该修改/usr/include中的文件。你可以通过运行以下命令找到gccinclude目录树：
```
gcc -print-libgcc-file-name
```
gcc头文件的目录通常从包含libgcc.a文件的同一目录开始。

某些Fortran子程序可能无法使用旧版本的Sun Fortran编译器编译。如果你得到类似以下的错误

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

在编译liboctave/external子目录中的Fortran子程序时，你应该升级编译器，或者尝试在不使用优化的情况下编译。

在NeXT系统上，如果你得到类似以下的错误：
```
/usr/tmp/cc007458.s:unknown:Undefined local
      symbol LBB7656
/usr/tmp/cc007458.s:unknown:Undefined local
      symbol LBE7656
```
在编译Array.cc和Matrix.cc时，尝试重新编译这些文件而不使用-g。
有些人报告说，在SunOS系统上对system()和分页器的调用不起作用。这显然是因为在编译libg++时，G_HAVE_SYS_WAIT被定义为0而不是1。
在使用引用的BLAS库时，以下矩阵-向量乘法错误地处理了形式为NaN * 0的NaN值。
```
[NaN, 1; 0, 0] * [0; 1]
⇒ 
[ 1
  0 ]

correct result ⇒ 
[ NaN
  0   ]
```
安装不同的BLAS库（如OpenBLAS或ATLAS）来修正此问题。
在NeXT系统上，链接到libsys_s.a可能无法解析以下函数
```
_tcgetattr
_tcsetattr
_tcflow
```
这些函数是libposix.a的一部分。不幸的是，使用-posix链接Octave会导致以下未定义符号。
```
.destructors_used
.constructors_used
_objc_msgSend
_NXGetDefaultValue
_NXRegisterDefaults
.objc_class_name_NXStringTable
.objc_class_name_NXBundle
```
解决此问题的一种方法是从libposix.a中提取termios.o，将其放到Octave的src目录中，并将其添加到makefile中要链接在一起的文件列表中。欢迎提出更好的解决方案！
如果Octave因浮点异常立即崩溃，很可能是由于未能初始化IEEE 754浮点值的无穷大和NaN。
如果你的系统确实支持IEEE 754算术，你应该能够通过修改lo-ieee.cc文件中的octave_ieee_init函数来正确初始化Octave的内部无穷大和NaN变量，从而修复此问题。

如果你的系统不支持IEEE 754算术，但Octave的配置脚本错误地确定它支持，你可以通过编辑config.h文件，不定义HAVE_ISINF、HAVE_FINITE和HAVE_ISNAN，来解决这个问题。

无论如何，请将其报告为错误，因为可能可以修改Octave的配置脚本来自动确定正确的操作。
如果Octave无法找到头文件，因为它安装在编译器通常不搜索的位置，你可以通过指定（例如）CPPFLAGS=-I/some/nonstandard/directory作为configure的参数，将目录添加到包含搜索路径中。可以通过这种方式指定的其他变量有CFLAGS、CXXFLAGS、FFLAGS和LDFLAGS。将它们作为选项传递给配置脚本也会将它们记录在config.status文件中。默认情况下，CPPFLAGS和LDFLAGS为空，CFLAGS和CXXFLAGS设置为"-g -O2"，FFLAGS设置为"-O"。