conflicting types for xx错误

conflicting types for xx错误

编译libvmi0.8版本时，出现以下错误：

libtool: compile:  gcc-DHAVE_CONFIG_H -I. -I.. -I.. -fvisibility=hidden-I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -g -O2 -MTlibvmi_la-pretty_print.lo -MD -MP -MF.deps/libvmi_la-pretty_print.Tpo -c pretty_print.c -fPIC -DPIC -o.libs/libvmi_la-pretty_print.o

pretty_print.c:31: error: conflicting types for‘vmi_print_hex’

libvmi.h:749:note: previous declaration of ‘vmi_print_hex’ was here

make[3]: ***[libvmi_la-pretty_print.lo] Fehler 1

make[3]: Leaving directory`/usr/local/src/libvmi-0.8/libvmi'

make[2]: *** [all-recursive]Fehler 1

make[2]: Leaving directory`/usr/local/src/libvmi-0.8/libvmi'

make[1]: *** [all-recursive]Fehler 1

make[1]: Leaving directory`/usr/local/src/libvmi-0.8'

make: *** [all] Fehler2

解决方案：

将libvmi/libvmi.h:void vmi_print_hex (unsigned char *data,unsigned long length);和

libvmi/pretty_print.c:void vmi_print_hex(unsigned char *data, size_tlength)

中的数据类型改为一致的即可。

见其论坛：https://groups.google.com/forum/?fromgroups#!topic/vmitools/w76m93KevFg

 

常见此类问题的原因如下（引）

错误：
test.c:22: error: conflictingtypes for 'urlencode'
test.c:18: error: previous implicit declaration of 'urlencode' washere

 

原因一：
原来是因为没有先做函数声明，而函数位于main()之后。
在main函数前声明了函数原型后，一切ok.

 

原因二：

头文件的被循环引用，在引用时考虑清楚包含顺序

 

原因三：

头文件声明和定义参数稍有不同

例：

 头文件中声明 void Hanlder(constchar * buf);

 在定义时写作 void Hanlder(char *buf);

这是就会发生conflictingtypes for 错误问题

winmain@16  错误一般是main 函数没有写 或者写错了。 程序需要入口。

undefined reference的错误原因分析-转

Linux下编译程序时，经常会遇到“undefined reference error”报错，这里总结一些可能的原因和解决方案： 

说到undefined reference error，先提一下Linux gcc链接规则

 

链接的时候查找顺序是:

 -L 指定的路径, 从左到右依次查找

由 环境变量LIBRARY_PATH 指定的路径,使用":"分割从左到右依次查找

/etc/ld.so.conf 指定的路径顺序

/lib 和/usr/lib (64位下是/lib64和/usr/lib64)

动态库调用的查找顺序: 

ld的-rpath参数指定的路径, 这是写死在代码中的

ld脚本指定的路径

LD_LIBRARY_PATH 指定的路径

/etc/ld.so.conf 指定的路径

/lib和/usr/lib(64位下是/lib64和/usr/lib64)

 

一般情况链接的时候采用-L的方式指定查找路径,调用动态链接库的时候采用LD_LIBRARY_PATH的方式指定链接路径.

 

另外注意一个问题,就是只要查找到第一个就会返回,后面的不会再查找. 比如-L./A -L./B -lx 在A中有libx.aB中有libx.a和libx.so, 这个时候会使用在./A的libx.a而不会遵循动态库优先的原则,因为./A是先找到的,并且没有同名动态库存在。

 

对于动态链接库，实际的符号定位是在运行期进行的．在编译.so的时候，如果没有把它需要的库和他一起进行联编，比如libx.so需要使用uldict,但是忘记在编译libx.so的时候加上-luldict的话，在编译libx.so的时候不会报错，因为这个时候libx.so被认为是一个库，它里面存在一些不知道具体实现的符号是合法的，是可以在运行期指定或者编译另外的二进制程序的时候指定．

 

如果是采用　g++ -Lpath -lx的方式进行编译，链接器会发现所需要的uldict的符号表找不到从而报错，但是如果是程序采用dlopen的方式载入，由于是运行期，这个程序在这个地方就直接运行报错了．另外还有一种情况就是一个对外的接口在动态库中已经声明定义了，但是忘记实现了，这个时候也会产生类似的错误．

 

如果在运行期报出这样的错误，就要注意是否是由于某些库没有链接进来或者某些接口没有实现的原因产生

有了上述基础，不难总结出，undefined reference error错误的原因可能来自以下几方面：

 

1 没有指定对应的库（.o/.a/.so）

使用了库中定义的实体，但没有指定库（-lXXX）或者没有指定库路径（-LYYY），会导致该错误,

 2 连接库参数的顺序不对

在默认情况下,对于-l 使用库的要求是越是基础的库越要写在后面,无论是静态还动态

 3 gcc/ld 版本不匹配

gcc/ld的版本的兼容性问题,由于gcc2到gcc3大版本的兼容性存在问题(其实gcc3.2到3.4也一定程度上存在这样的问题)当在高版本机器上使用低版本的机器就会导致这样的错误, 这个问题比较常见在32位的环境上,另外就在32位环境不小心使用了64位的库或者反过来64位环境使用了32位的库.

 4 C/C++相互依赖和链接

gcc和g++编译结果的混用需要保证能够extern "C"两边都可以使用的接口,在我们的64位环境中gcc链接g++的库还需要加上-lstdc++,具体见前文对于混合编译的说明

 5 运行期报错

这个问题基本上是由于程序使用了dlopen方式载入.so,但.so没有把所有需要的库都链接上,具体参加上文中对于静态库和动态库混合使用的说明