libiconv库的编译
想把libiconv库移植到6410板子上,在fedora14,交叉工具链4.5.1下交叉编译libiconv-1.14.tar.gz,./configure --prefix=/usr/local/libiconv CC=arm-linux-gcc --enable-shared --enable-static --host=arm-linux,make make install,编译一个测试的.c文件,arm-linux-gcc -o 1 1.c -libiconv,出现如下错误:。。/bin/ld:cannot find -libiconv,改为arm-linux-gcc -o 1 1.c -Llibiconv,又出现如图所示的错误:,但是我查了一下iconv.h有啊,为什么会出现这个错误,天嵌以前楚歌关于linux下的编码转换的一个库,那个是4.3.3编译好的,求解决啊 本帖最后由 TQ-lkp 于 2012-8-20 18:19 编辑
arm-linux-gcc -o 1 1.c -libiconv
应为:
arm-linux-gcc -o 1 1.c -L. -liconv 不行啊,,
我发现iconv.h文件里面的#ifndef LIBICONV_PLUG
#define iconv_open libiconv_open,而LIBICONV_PLUG不知道在哪儿打开的,自己定义#define LIBICONV_PLUG
但是又不行,arm-linux-readelf -a |grep "Shared"发现只有libc.so.6,并没有libiconv库,不知道天嵌的那个linux下编码库的那个libicon.a是怎么静态编译的 iconv.h文件里面注视说We would like to #include any system header file which could define
iconv_t, 1. in order to eliminate the risk that the user gets compilation
errors because some other system header file includes /usr/include/iconv.h
which defines iconv_t or declares iconv after this file, 2. when compiling
for LIBICONV_PLUG, we need the proper iconv_t type in order to produce
binary compatible code. But gcc's #include_next is not portable. Thus, once libiconv's iconv.h
has been installed in /usr/local/include, there is no way any more to
include the original /usr/include/iconv.h. We simply have to get away
without it.
Ad 1. The risk that a system header file does
#include "iconv.h"or#include_next "iconv.h"
is small. They all do #include <iconv.h>.
Ad 2. The iconv_t type is a pointer type in all cases I have seen. (It
has to be a scalar type because (iconv_t)(-1) is a possible return value
from iconv_open().) 纠结:'(:'(:'(:'(:'( arm-linux-gcc -o 1 1.c -liconv,刚刚试了一下可以了,明天去6410板子上试一试,
页:
[1]