本人在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形式的静态库）。