我正在编写一个使用ncurses的应用程序。
在Debian和Ubuntu中，我可以选择这些包：
w版本包含wide-char支持，这就是我想要的。
但是，如果我只安装libndursesw5-dev，当我使用-lncurses或-lncursesw进行编译时会收到一条错误消息，告知我它无法找到curses.h }或ncurses.h。
同时安装libncurses5-dev和libncursesw5-dev并使用-lncursesw有效，但我不确定这是否正确，或者只是巧合似乎可行。使用-lncurses将引入一个非宽字符库。
作为参考，在Mac OS X 10.11上，-lncurses有效（支持广泛字符），而-lncursesw根本不起作用。
答案 0 :(得分：1)
Debian安装两个标题
/usr/include/curses.h
/usr/include/ncursesw/curses.h
作为兼容性的解决方法。后者“大部分”兼容，但仅限于编译时。例如，WINDOW结构在后者中更大。第一个（/usr/include/curses.h）是“标准”，但在ncursesw库之前已有几年了。因为移植ncurses的一些平台不使用ncurses作为系统curses库（例如，Solaris），所以规定将ncurses的头部放在子目录中以避免覆盖（或冲突）系统的标准{{1 （请参阅ncurses常见问题 Is the ncurses library compatible with my system? ）。
由于Debian以ncurses作为系统curses库开始，因此其包装商选择使用相同的解决方法来避免ncurses和ncursesw之间的冲突。其他一些系统上的打包器可以选择将两个放在子目录中，并在其包装脚本中建立链接，如
curses.h我记得Cygwin做过类似的事情，省略了/usr/include/curses -> /usr/include/curses/ncurses.h
的链接（一个错误，因为它也是一个标准的标题）。
对于OSX，系统只提供ncurses（而不是ncursesw），大多数人使用ncursesw通过安装 ncursesw 标头的MacPorts这样做（如果应用程序定义了{编译ncursesw时{1}}
因为unctrl.h的声明ifdef将允许任何一个库得到支持）。 Debian打包器更加谨慎，并选择将标题分开。