linux 链接器 : '-lpng' inhibits '-lz' ?

Question

在 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.so 中找到的，但是链接器没有使用它!

一个偶然的机会，我想去掉-lpng选项(实际上，没有使用libpng库)，我的问题就解决了!为什么？

其次，我用另一个版本的GCC-4.7.3编译我的整个代码(自己编译——我习惯测试很多版本的编译器)，并没有出现错误，即使同时使用-lpng 和 -lz!

有什么想法吗？

此外，使用另一个程序(使用 libpng)进行不同的尝试会导致构建成功。

编辑于 2013-10-08

现在我很确定它是 ubuntu-13.04 中的一个错误:我已经尝试了另外两个 linux 发行版(Fedora 16 -- Ubuntu-10.04)并且链接器行为是标准的，而不是上面第一个中描述的那样我的信息的一部分。

我打算在 ubuntu 社区上报告这个问题。问候。

编辑于 2013-10-09

错误已报告给https://bugs.launchpad.net/ubuntu/+source/gcc-defaults/+bug/1237270

Answer 1

两个可能的修复(直到 ubuntu 不 self 修复):

1. 尝试将libpng.a和libz.a编译为静态库(这只能是临时解决方案，因为静态库是邪恶的大多数情况下)。

2. 从原始源代码重新编译libpng，并将此处的libz.a编译为static。