本人在win10下安装了mingw环境,以方面windows下测试gcc编译器构建一些开源组件。但是windows系统下遇到了一些编译问题。

1. 问题现象

  一次手写的Makefile遇到了如下编译错误:

1 $ make
2 g++ -I ../include  -fPIC -c JpegDecoder.cpp -o JpegDecoder.o
3 g++ -o JpegDecoder JpegDecoder.o -L../libs -lcodec_utils
4 d:/ProgramFiles/mingw-w64/mingw32/bin/../lib/gcc/i686-w64-mingw32/8.1.0/../../../../i686-w64-mingw32/bin/ld.exe: cannot find -lcodec_utils
5 collect2.exe: error: ld returned 1 exit status
6 make: *** [JpegDecoder] Error 1

  可是,在linux平台上编译这段代码完全没问题。。。见什么鬼了???

2. 错误原因分析

  直接提示表明,欲生成JpegDecoder的可执行文件,需要链接动态库libcodec_utils.so,但是找不到这个这个库文件(自定义的库文件),因此出现了这个链接错误提示。

3. 编译知识回顾

  一般理论常识是:-L参数指定了库的目录,-lxyz参数指定库名。例如,本次链接的动态名称为libcodec_utils.so,该库位于上级目录的libs文件夹下。

4. 疑问

  我再次确认,库目录和库文件都存在,Makefile写的应该没问题!况且在Linux平台下编译通过了!但为什么在win下还是报错???

5. 答案分析

  由于使用的连接器ld.exe是运行在window系统下的,可能跟linxu平台下的使用方法稍有区别。

  windows下查看命令行查看:ld --help,找到了一些链接参数信息:

  

   其中,-l LIBNAME表示,要写成-l libcodec_utils.so形式,而不能做一些省略,例如去掉“lib”和“.so”。(真正验证时,还不是这种情况!!!

  在Linux平台下,显示一样的信息。可能是linux平台下,将参数"-lcodec_utils"自动补全为"-l libcodec_utils.so"形式。

6. 验证结论

  6.1 参数形式:"-L../libs -lcodec_utils"

  

  6.2 参数形式:"-L../libs -l libcodec_utils.so"

  

   注意,错误提示跟6.1的稍微有些区别,系统自动添加了前缀"-l"到库名前,变成了"-llibcodec_utils.so"库找不到。

  6.3 参数形式:"-L../libs libcodec_utils.so"

  

  这是(目前验证到的、可行的,其他方式或许有,但还没找到)在windows平台下唯一的正确的参数。

  6.4 链接系统的函数库,可以使用"-lxyz"形式;若链接自定义的库,不能使用该形式,库名必须写完整。

  补充:-lxyz是使用的系统静态库(查看gcc编译时的细节信息,使用-v参数,再去路径下可以看到,系统自动添加了一些基础库用于链接,但这些基础库都是.a形式的静态库)。