Unix | Tony Bai

标签 Unix 下的文章

libiconv库链接问题一则

四月 25, 2013
2 条评论

与在Solaris系统上不同，Linux的libc库中包含了libiconv库中函数的定义，因此在Linux上使用libiconv库相关函数，编译时是不需要显式-liconv的。但最近我的一位同事在某redhat enterprise server 5.6机器上编译程序时却遇到了找不到iconv库函数符号的链接问题，到底是怎样一回事呢？这里分享一下问题查找过程。

一、现场重现

这里借用一下这位同事的测试程序以及那台机器，重现一下问题过程：
/*test.c */

…
#include <iconv.h>

int main(void)
{
    int r;
    char *sin, *sout;
    size_t lenin, lenout;
    char *src = "你好!";
    char dst[256] = {0};
    iconv_t c_pt;

sin = src;
lenin = strlen(src)+1;

sout = dst;
lenout = 256;

    if ((c_pt = iconv_open("UTF-8", "GB2312")) == (iconv_t)(-1)){
        printf("iconv_open error!. errno[%d].\n", errno);
        return -1;
    }

    if ((r = iconv(c_pt, (char **)&sin, &lenin, &sout, &lenout)) != 0){
        printf("iconv error!. errno[%d].\n", r);
        return -1;
    }

iconv_close(c_pt);

printf("SRC[%s], DST[%s].\n", src, dst);

return 0;
}

根据之前的经验，我们按如下命令编译该程序：

$> gcc -g -o test test.c

/tmp/ccyQ5blC.o: In function `main':
/home/tonybai/tmp/test.c:28: undefined reference to `libiconv_open'
/home/tonybai/tmp/test.c:33: undefined reference to `libiconv'
/home/tonybai/tmp/test.c:38: undefined reference to `libiconv_close'

咦，这是咋搞的呢？怎么找不到iconv库的符号！！！显式加上iconv的链接指示再试试。

$> gcc -g -o test test.c -liconv

这回编译OK了。的确如那位同事所说出现了怪异的情况。

二、现场取证

惯性思维让我首先提出疑问：难道是这台机器上的libc版本有差异，检查一下libc中是否定义了iconv相关符号。

$ nm /lib64/libc.so.6 |grep iconv
000000397141e040 T iconv
000000397141e1e0 T iconv_close
000000397141ddc0 T iconv_open

iconv的函数都定义了呀！怎么会链接不到？

我们再来看看已经编译成功的那个test到底连接到哪个iconv库了。

$ ldd test
    linux-vdso.so.1 => (0x00007fff77d6b000)
    libiconv.so.2 => /usr/local/lib/libiconv.so.2 (0x00002abbeb09e000)
    libc.so.6 => /lib64/libc.so.6 (0×0000003971400000)
    /lib64/ld-linux-x86-64.so.2 (0×0000003971000000)

哦，系统里居然在/usr/local/lib下面单独安装了一份libiconv。gcc显然是链接到这里的libiconv了，但gcc怎么会链接到这里了呢？

三、大侦探的分析^_^

Gcc到底做了什么呢？我们看看其verbose的输出结果。

$ gcc -g -o test test.c -liconv -v
使用内建 specs。
目标：x86_64-redhat-linux
配置为：../configure –prefix=/usr –mandir=/usr/share/man –infodir=/usr/share/info –enable-shared –enable-threads=posix –enable-          checking=release –with-system-zlib –enable-__cxa_atexit –disable-libunwind-exceptions –enable-libgcj-multifile –enable-languages=c,c++,   objc,obj-c++,java,fortran,ada –enable-java-awt=gtk –disable-dssi –disable-plugin –with-java-home=/usr/lib/jvm/java-1.4.2-gcj-1.4.2.0/jre –with-cpu=generic –host=x86_64-redhat-linux
线程模型：posix
gcc 版本 4.1.2 20080704 (Red Hat 4.1.2-50)
/usr/libexec/gcc/x86_64-redhat-linux/4.1.2/cc1 -quiet -v test.c -quiet -dumpbase test.c -mtune=generic -auxbase test -g -version -o /tmp/     ccypZm0v.s
忽略不存在的目录“/usr/lib/gcc/x86_64-redhat-linux/4.1.2/../../../../x86_64-redhat-linux/include”
#include "…" 搜索从这里开始：
#include <…> 搜索从这里开始：
/usr/local/include
/usr/lib/gcc/x86_64-redhat-linux/4.1.2/include
/usr/include
搜索列表结束。
GNU C 版本 4.1.2 20080704 (Red Hat 4.1.2-50) (x86_64-redhat-linux)
    由 GNU C 版本 4.1.2 20080704 (Red Hat 4.1.2-50) 编译。
GGC 准则：–param ggc-min-expand=100 –param ggc-min-heapsize=131072
Compiler executable checksum: ef754737661c9c384f73674bd4e06594
as -V -Qy -o /tmp/ccaqvDgX.o /tmp/ccypZm0v.s
GNU assembler version 2.17.50.0.6-14.el5 (x86_64-redhat-linux) using BFD version 2.17.50.0.6-14.el5 20061020
/usr/libexec/gcc/x86_64-redhat-linux/4.1.2/collect2 –eh-frame-hdr -m elf_x86_64 –hash-style=gnu -dynamic-linker /lib64/ld-linux-x86-64.so. 2 -o test /usr/lib/gcc/x86_64-redhat-linux/4.1.2/../../../../lib64/crt1.o /usr/lib/gcc/x86_64-redhat-linux/4.1.2/../../../../lib64/crti.o /usr/   lib/gcc/x86_64-redhat-linux/4.1.2/crtbegin.o -L/usr/lib/gcc/x86_64-redhat-linux/4.1.2 -L/usr/lib/gcc/x86_64-redhat-linux/4.1.2 -L/usr/lib/gcc/ x86_64-redhat-linux/4.1.2/../../../../lib64 -L/lib/../lib64
-L/usr/lib/../lib64 /tmp/ccaqvDgX.o -liconv -lgcc –as-needed -lgcc_s –no-as-needed -lc -lgcc –as-needed -lgcc_s –no-as-needed /usr/lib/gcc/x86_64-redhat-linux/4.1.2/crtend.o /usr/lib/gcc/x86_64-redhat-linux/4.1.2/../../../../lib64/crtn.o

从这个结果来看，gcc在search iconv.h这个头文件时，首先找到的是/usr/local/include/iconv.h，而不是/usr/include/iconv.h。这两个文件有啥不同么？

在/usr/local/include/iconv.h中，我找到如下代码：

…
#ifndef LIBICONV_PLUG
#define iconv_open libiconv_open
#endif
extern iconv_t iconv_open (const char* tocode, const char* fromcode);
…

libiconv_open vs iconv_open，卧槽！！！再对比一下前面编译时输出的错误信息：

大侦探醒悟了！大侦探带你还原一下真实情况。

我们在执行gcc -g -o test test.c时，根据gcc -v中include search dir的顺序，gcc首先search到的是/usr/local/include/iconv.h，而这里iconv_open等函数被预编译器替换成了libiconv_open等加上了lib前缀的函数，而这些函数符号显然在libc中是无法找到的，libc中只有不带lib前缀的 iconv_open等函数的定义。大侦探也是一时眼拙了，没有细致查看gcc的编译错误信息中的内容，这就是问题所在！

而gcc -g -o test test.c -liconv为何可以顺利编译通过呢？gcc是如何找到/usr/local/lib下的libiconv的呢？大侦探再次为大家还原一下真相。

我们在执行gcc -g -o test test.c -liconv时，gcc同样首先search到的是/usr/local/include/iconv.h，然后编译test.c源码，ok；接下来启动ld程序进行链接；ld找到了libiconv，ld是怎么找到iconv的呢，libiconv在/usr/local/lib下，ld显然是到这个目录下search了。我们通过执行下面命令可以知晓ld的默认搜索路径：

$> ld -verbose|grep SEARCH
SEARCH_DIR("/usr/x86_64-redhat-linux/lib64"); SEARCH_DIR("/usr/local/lib64"); SEARCH_DIR("/lib64"); SEARCH_DIR("/usr/lib64"); SEARCH_DIR("/usr/x86_64-redhat-linux/lib"); SEARCH_DIR("/usr/lib64"); SEARCH_DIR("/usr/local/lib"); SEARCH_DIR("/lib"); SEARCH_DIR("/usr/lib");

ld的默认search路径中有/usr/local/lib(我之前一直是以为/usr/local/lib不是gcc/ld的默认搜索路径的)，因此找到libiconv就不足为奇了。

四、问题解决

我们不想显式的加上-liconv，那如何解决这个问题呢？我们是否可以强制gcc先找到/usr/include/iconv.h呢？我们先来做个试验。

$ gcc -g -o test test.c -liconv -I ~/include -v
…
忽略不存在的目录“/usr/lib/gcc/x86_64-redhat-linux/4.1.2/../../../../x86_64-redhat-linux/include”
#include "…" 搜索从这里开始：
#include <…> 搜索从这里开始：
/home/tonybai/include
/usr/local/include
/usr/lib/gcc/x86_64-redhat-linux/4.1.2/include
/usr/include
搜索列表结束。

…

试验结果似乎让我们觉得可行，我们通过-I指定的路径被放在了第一的位置进行search。我们来尝试一下强制gcc先search /usr/include。

$ gcc -g -o test test.c -I ~/include -v
…
忽略不存在的目录“/usr/lib/gcc/x86_64-redhat-linux/4.1.2/../../../../x86_64-redhat-linux/include”
忽略重复的目录“/usr/include”
因为它是一个重复了系统目录的非系统目录
#include "…" 搜索从这里开始：
#include <…> 搜索从这里开始：
/usr/local/include
/usr/lib/gcc/x86_64-redhat-linux/4.1.2/include
/usr/include
搜索列表结束。
…

糟糕！/usr/include被忽略了！还是从/usr/local/include开始，方案失败。

似乎剩下的唯一方案就是将/usr/local/lib下的那份libiconv卸载掉！那就这么做吧^_^！

一种基于内存映射文件的系统运行数据提取方法

三月 18, 2013
3 条评论

这是我无意中想到的一个方法，估计这个方法已经不是什么新鲜的东西了，很可能在类似的问题场景中早已经被使用了。不过这里还是要说说我的思维过程。

近期在学习一些Linux性能查看和分析方面的工具，比如top、iostat、vmstat以及sar等。在学习过程中我发现这些工具有个共同的特点，那就是她们采集的Linux运行数据都是从/proc下的文件中实时获取并计算而得出的。众所周知，/proc是Linux内核维护的一个虚拟文件系统，他允许用户在Linux运行时查看内核运行数据（用户可以像查看普通文件一样查看/proc下的目录和文件），甚至是运行时实时改变内核设置。Linux实现/proc的细节不是这里要关注的，吸引我的是Linux的这种提取运行数据的设计。这个设计将Linux运行数据的产生实现细节与第三方性能采集工具间的耦合最大化地解开，这样一来/proc就像是一种Linux的基础服务，为用户提供一种实时的运行数据信息。而用户侧的运行数据查看工具也可以根据用户的需求自由定制，因此有了top、iostat、vmstat、iotop、sar等关注点不同的工具。

好了，说完/proc后，再来说说我们的产品。用户长期以来一直在抱怨我们的产品监控和维护方面手段太过单一，产品就像是一个黑盒，没有提供一种自我运行观察的能力，让客户看不清阿看不清，用户无法实时获取当前某个节点上的业务运行状况，无法采集到这些业务运行的实时基础数据，这的确是我们长期以来的短板（以前这块受重视度也的确不足）。虽然这两年我们在改善运维手段方面的投入已经加大，并收到一些显著的效果，但方案都是集中的，且相对重量级的，不那么敏捷灵活 – 在单节点上依旧无法简单地获取该节点的运行数据。

结合/proc的设计以及我们所遇到的问题，我有了一个大胆的想法：是否可以给我们的业务系统也加上一种类似Linux /proc这样的可提供基础运行数据的服务能力呢？于是就有了下面的解决方法。

Linux /proc下面的数据文件是Linux Kernel维护的，并允许用户层的进程实时查看和配置数据。而对于我们的产品而言，提供基础数据的产品实例与提取基础数据的第三方程序是两个独立的用户level的进程，显然我们需要找到一种让这两个进程实时通信、低耦合的且性能代价极低的方法。

我首先想到的是文件，这似乎和/proc的方式一样。你查看一下sysstat源码会发现，像iostat、sar等工具都是用fopen以"r"方式打开/proc/下的各种stat文件，匹配和读取指标项后再统计的。但在User层，两个无亲缘关系进程共同操作一个文件 – 一个读，一个写，the file position indicator是很难控制的，可能涉及文件锁(flock/fcntl)，还要考虑使用的库函数是否是带缓冲的（fread/fgets都是带缓冲的，不能用），写端需要及时fsync/fflush。总而言之，这么做是甚为自讨没趣的，会给两个程序的实现都带来很大的复杂性以及各种“坑”的。

那用named fifo如何呢？一但用named fifo，这两个进程就会产生启动依赖，如果一端没有启动，另一端会一直阻塞；而且通过fifo传递多种业务数据还可能存在打包和解包的过程，实现起来复杂的很。这显然是耦合十分严重的糟糕方案。

两个进程既要有共同的识别目标，就像/proc/cpuinfo这样的已知路径，一个进程还要能及时地得到另外一个进程运行时的数据，我们不妨尝试一下内存文件映射这个方案：运行数据提供的进程映射一个已知目标文件，比如perf/xxstat，然后在映射后的地址上创建和更新指标数据。比如我们建立一个整型数组，数组的每个元素都代表一种运行指标；而运行数据提取进程同样映射该文件，并在映射后获得数组中的各个元素值。下面是一个示例程序：

/* producer */
int
main()
{
FILE *fp = NULL;

errno = 0;
fp = fopen(STAT_FILE, "w+");
if (fp == NULL) {
printf("can not create stat file , err = %d\n", errno);
return -1;
}

errno = 0;
long size = sysconf(_SC_PAGESIZE);
if (ftruncate(fileno(fp), size) != 0) {
printf("can not set stat file size, err = %d\n", errno);
fclose(fp);
return -1;
}

errno = 0;
char *p = NULL;
p = mmap(NULL, size, PROT_WRITE|PROT_READ, MAP_SHARED, fileno(fp), 0);
if (p == MAP_FAILED) {
printf("can not mmap file, error = %d\n", errno);
fclose(fp);
return -1;
}

errno = 0;
if (fclose(fp) != 0) {
printf("can not close file, error = %d\n", errno);
return -1;
}

/* round up to 8 */
while((int)p % 8 != 0) {
p++;
}

long long *q = (long long*)p;
q[0] = 1;
q[1] = 1000;
q[2] = 10000;
q[3] = 100000;

while(1) {
q[0] += 1;
q[1] += 10;
q[2] += 100;
q[3] += 1000;
usleep(200);
}

return 0;
}

该producer程序首先尝试以"w+"方式打开xxstat文件，并设置文件的大小，然后调用mmap做内存文件映射，理论上来说mmap成功时返回的地址一定是按该平台下最严格内存系数对齐的地址，但这里为了安全起见，又做了一次内存地址的圆整。producer以映射的地址为首地址，建立了一个包含四个元素的、每个元素大小为8字节的整型数组，其中每个元素模拟一个运行指标。在while(1)循环中，producer模拟更新这四个指标数据。

下面是提取producer运行数据的例子程序，其映射过程与producer类似，这里就不贴出完整代码了，完整代码可在这里下载。

/* reader.c */

int
main()
{
FILE *fp = NULL;
… …

char *p = NULL;
p = mmap(NULL, size, PROT_READ,
MAP_SHARED, fileno(fp), 0);
if (p == MAP_FAILED) {
printf("can not mmap file, error = %d\n", errno);
fclose(fp);
return -1;
}

… …

long long *q = (long long*)p;

while(1) {
printf("%lld\t\t%lld\t\t%lld\t\t%lld\n", q[0], q[1], q[2], q[3]);
sleep(1);
}

return 0;
}

在producer执行一段时间后，我们可以用reader去提取producer的实时运行数据了。

$ reader
2583 26820 268200 2682000
5793 58920 589200 5892000
9142 92410 924100 9241000
12431 125300 1253000 12530000
15586 156850 1568500 15685000
… …

需要注意的是两个进程映射的虽然是同一个文件，但各自进程空间映射的地址是不同的。如果在指标里存储地址数据，那另外一个进程在访问该地址时必然会出现问题。

在这个方案中，由于两个进程是读写同一块内存(虽然在各自进程空间的地址是不同的），因此数据是实时的。但由于两个进程间并没有任何同步机制，可能会产生误差，就好比一个进程中的两个线程对进程中某块地址空间一读一写这种情况一样。不过对于我们这种场景，这个问题是一般是可以被容忍和接受的，毕竟我们通过运行数据只是想了解一种运行趋势而已。如果producer中存在多个有亲缘关系的子进程或多线程要同时更新基础运行数据，那势必是要用锁或其他原子操作做数据操作的同步的。另外我们用的是内存映射具名的文件，OS会定期将数据刷到磁盘上，不过这个消耗对于小文件来说，对整体性能影响可忽略不计。

一旦业务系统具备了提供基础运行数据的能力，我们就可以根据我们的需求按照数据的格式打造我们所需要的各类数据提取和分析工具了。如果需要长期记录业务系统的运行情况，我们也可以实现类似sar这样的工具，以在后台定期对系统的运行数据进行记录，并提供历史查询等相关功能。

这种基于内存映射文件的方法还有一个好处，那就是我们可以用任何支持mmap调用的编程语言来实现数据提取工具，而不一定非得用C/C++这种原生适配Linux API的语言。

如果你觉得这种方案可行，那后续的重点就是基础运行数据的设计问题了。罗马不是一天建成的，/proc下的基础数据也不是一天就设计到位的。在基础数据设计这方面也是需要有很多考虑的，比如是文本还是二进制，用什么类型数据，还可能需要考虑一些数据对齐问题等。当然这就不是本文的重点了，就不细说了。