Sos*_*sos 3 c++ macos makefile iconv
我正在尝试在 OSX上构建gnu iconv作为静态库。这不是问题,它可以很好地构建
./configure --enable-static
make clean && make
Run Code Online (Sandbox Code Playgroud)
但是当我在 libiconv.a 上运行 nm 时,我得到以下结果
...
_libiconv
_libiconv_open_
_libiconv_close_
...
Run Code Online (Sandbox Code Playgroud)
这是有问题的,因为我想使用这个库构建 libxml2,它需要以下符号
iconv
iconv_open
iconv_close
Run Code Online (Sandbox Code Playgroud)
查看头文件,似乎这两个符号名称之间的区别在于是否定义了 LIBICONV_PLUG。但是当我运行 make as
make clean && make CPPFLAGS=-DLIBICONV_PLUG
Run Code Online (Sandbox Code Playgroud)
我收到错误是因为有几件事没有定义,例如ICONV_GET_DISCARD_ILSEQ 和ICONV_SET_HOOKS。再次查看头文件,这些仅在未定义 LIBICONV_PLUG 时才定义。
我的问题是,我是否正确使用了 LIBICONV_PLUG?还有其他方法可以使用我需要的符号来获取静态库吗?我应该查看未定义的符号并自己手动定义它们吗?
有三种可能的方式来构建和使用 GNU libiconv。在所有三种情况下,它定义供 C 或 C++ 程序(通过头文件)使用的符号是“iconv_open”、“iconv”、“iconv_close”。
正常的一种是,在目标文件级别,它定义了符号“libiconv_open”等,以免与操作系统的标准库发生冲突。C 级符号和目标文件级符号之间的映射发生在 <iconv.h> 中。
如果将系统的 <iconv.h> 与 GNU libiconv.{so,dylib,a} 一起使用,则会出现链接错误,反之亦然。这是一个特性,因为两者的特性略有不同(OS X libiconv.dylib 支持名为“UTF-8-MAC”的编码,而 GNU libiconv 有许多改进和修复),不匹配会导致问题。
如果您是系统供应商,您可以以定义“iconv_open”而不是“libiconv_open”等的方式构建 GNU libiconv。这是通过简单编辑 iconv.h 来实现的。
或者,特别是在 OS X 上,您可以从https://opensource.apple.com/选择 libiconv并为自己编译。但请注意,此版本基于 GNU libiconv 1.11,也就是说,它已经很老了。
正如 GNU libiconv 的 README 中所解释的,LIBICONV_PLUG 标志创建了一个库,它将覆盖系统中的功能;这仅适用于 GNU、Solaris 和 OSF/1。
在您的情况下,您只想让某些免费软件包(例如 libxml2)使用 GNU libiconv,最简单的方法是采用第一种方法,并在该软件包的编译期间,使用 -I 和 -L 选项来让它找到 GNU libiconv 头文件和库。
事实上,libxml2 使这一切变得简单:它的配置脚本已经有一个选项 --with-iconv= prefix,通过它您可以指定安装 GNU libiconv 的目录层次结构(前缀/include/ 中的头文件和目标文件在前缀/lib/); 然后配置脚本将综合适当的 -I 和 -L 选项。