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编译好的，求解决啊

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板子上试一试，