静态链接后资源中的qt png已损坏

我们正在linux上开发一个相当大的基于Qt的项目，我们已经达到了RC1的最后阶段

现在，我们遇到了一件非常奇怪的事情：为了投入生产，我们在静态链接库列表中添加了另一个.a库

库已链接且应用程序正在运行，但资源文件中的每个.png都已损坏，以下是启动时的输出：

libpng错误：IHDR:CRC错误

看起来libpng无法处理那些无效的png（当然）。文件在那里，大小合适，在静态链接最终的库之后，它们变成空白。库本身没有在任何地方使用，它只是链接

---

以前有人遇到过这样的情况吗？是否有已知的解决方法？我们正在QtCreator 2.3.0上使用Qt 4.7.4 x64，我们现在不想升级，但这是我们现在想到的唯一选项。

它可能适合符号问题。 静态库和libpng可以同时链接到其他库，当在编译/加载时链接或解析时，会发生一些奇怪的事情

可以使用objdump命令检查符号（objdump-tT/usr/bin）

编译/链接时是否尝试过修改库顺序？我是说，比如说

gcc -lmylibrary -lQt -lOtherLOLibrary 

而不是

gcc -lOtherLOLibrary -lQt -lmylibrary

---

我想我遗漏了一些东西，为什么要链接到未使用的库？

更改优化设置会影响它吗？使用最新的Qt版本创建一个隔离的环境，并进行构建只是为了看看这是否是Qt问题，而不是编译器/libpng问题。切换到Qt 4.8.1/QtCreator 2.4.1并禁用优化不会产生任何结果尝试在资源中删除并重新添加png，没有效果。崩溃@QImage（：/icons/.png”）.constBits（）；奇怪的是，资源中的所有其他非png文件都很好。试图强制qrc根本不使用压缩（即使png在默认值的70%以下）没有效果。QImage（）返回一个空的QImage。当然，它不是用来不使用的，我们将在解决此集成问题后立即使用它。为了调试的目的，它没有被使用。太好了，现在清楚了。但是，现在，仅仅更改这个编译库的“标志”就可以区别工作和不工作了？更改标志顺序不会产生任何效果。我注意到objdump同时声明了.a和libpng.so declare:000000000000 DF_UND 0000000000 crc32（在libpng中），而在.a 00000000000000000000 F.text 000000000000 2e crc32中，内部变量（称为crc32）可能存在冲突？不幸的是，我们无法控制它，已经联系了团队，但没有得到任何答案，也不知道它是否可行，或者他们是否会改变它。好吧，我们放弃了libpng，转而使用tiff转换每个png，虽然不优雅，但肯定比让人重写更快（我们只有25个png）