linux链接器：'-lpng&x27；抑制'-lz'；？

在ubuntu-13.04上，我使用linux发行版提供的GCC-4.7.3从共享库构建可执行文件时出错

我想问题出在libpng和zlib之间（前者使用后者），但我不知道为什么

首先，我的命令是：

$ gfortran -o test_muesli_config_fml test_muesli_config_fml.o -fopenmp 
-Wl,--rpath,/usr/local/lib/muesli /usr/local/lib/muesli/libfml.so -lstdc++
-Wl,--rpath,/usr/lib /usr/lib/liblapack.so -Wl,--rpath,/usr/lib /usr/lib/libblas.so
-lpng -lz -lpthread -lreadline -lhistory

这会产生以下错误：

/usr/local/lib/muesli/libfml.so: undefined reference to `gzwrite'
/usr/local/lib/muesli/libfml.so: undefined reference to `gzopen'
/usr/local/lib/muesli/libfml.so: undefined reference to `gzclose'
/usr/local/lib/muesli/libfml.so: undefined reference to `gzread'
collect2: error: ld returned 1 exit status

但是请注意，

-lz

是存在的。之后，我添加了链接器选项

--trace symbol=

，以获取更多信息：

$ gfortran -o test_muesli_config_fml test_muesli_config_fml.o -fopenmp 
-Wl,--rpath,/usr/local/lib/muesli /usr/local/lib/muesli/libfml.so -lstdc++
-Wl,--rpath,/usr/lib /usr/lib/liblapack.so -Wl,--rpath,/usr/lib /usr/lib/libblas.so
-lpng -lz -lpthread -lreadline -lhistory -Wl,--trace-symbol=gzwrite

从而得出以下结果：

/usr/local/lib/muesli/libfml.so: reference to gzwrite
/usr/lib/gcc/x86_64-linux-gnu/4.7/../../../x86_64-linux-gnu/libz.so: definition of gzwrite
/usr/local/lib/muesli/libfml.so: undefined reference to `gzwrite'
/usr/local/lib/muesli/libfml.so: undefined reference to `gzopen'
/usr/local/lib/muesli/libfml.so: undefined reference to `gzclose'
/usr/local/lib/muesli/libfml.so: undefined reference to `gzread'
collect2: error: ld returned 1 exit status

所以，

gzwrite

可以在

libz中找到。所以

但是链接器不使用它

碰巧，我想删除

-lpng

选项（实际上，没有使用libpng库），我的问题就解决了！为什么?

其次，我用另一个版本的GCC-4.7.3编译了我的全部代码（由我自己编译——我习惯于测试编译器的许多版本），即使同时使用

-lpng

和

-lz

，错误也没有发生

有什么想法吗

此外，对另一个程序（使用libpng）进行不同的尝试将导致成功构建

于2013年10月8日编辑

现在我很确定这是ubuntu-13.04中的一个bug：我已经尝试了另外两个linux发行版（Fedora 16--ubuntu-10.04），链接器的行为是标准的，而不是我消息的第一部分所描述的

我计划在ubuntu社区报告这个问题。问候

于2013年10月9日编辑

该漏洞已报告给两个可能的修复程序（直到ubuntu无法自行修复）：

尝试在

libpng.a

和

libz.a

中编译为静态库（它只能是一个临时解决方案，因为静态库在大多数情况下都是有害的）

从原始源代码重新编译libpng，并将

libz.a

编译为静态

---

如果在链接器命令行中颠倒-lpng和-lz的顺序会怎么样？虽然我认为顺序只对静态LIB重要…但我已经尝试了很多方法，比如多个lz出现：什么都不给！可能是（Ubuntu的）libpng定义这些符号的方式使它们无法进一步解析，导致libz被忽略（这些符号已经获得），但不允许使用它们吗？我知道这听起来很疯狂，但这就是我在这里看到的。我猜libpng上的

nm

或

objdump

，并将libz符号与适当的libz进行比较可能会对此有更多的了解。