我用inkscape编译了libpng16。尽管如此，ldd仍然需要libpng15。因此，我怀疑链接的库之一可能是罪魁祸首。我编写了一个程序，该程序递归ldd的所有库，而且似乎都不需要libpng15。
inkscape自己需要libpng15 和 libpng16？ Inkscape运行正常，直到我尝试导出PNG图像，然后消息为：
libpng警告：使用libpng-1.6.16构建但使用1.5.13运行的应用程序
注意：我检测到lddtree.sh，这似乎是相同的，是的，结果与我编写的脚本相同！
答案 0 :(得分：0)
好吧，这个问题花了相当长的时间才能解决。我当然不是复杂的parse-dashboard --appId yourAppId --masterKey yourMasterKey --serverURL "https://example.com/parse" --appName optionalName
parse-dashboard --appId yourAppId --masterKey yourMasterKey --serverURL "https://example.com/parse" --appName optionalName，静态和动态链接等方面的专家，这可能是造成混淆的原因之一。
这里发生了什么？看来Inkscape使用两种类型的库。普通的外部库（可由gcc和g++控制，但也有十几个内部库（其中一些是外部库的私有副本，例如--enable-static），不受-shared和朋友的控制，但需要自己请求库：
libcroco这些“内部”库似乎总是静态链接的。它们神奇地出现在最终链接行上。似乎无法控制它们与--enable-static系统引入的共享库的兼容性。
在我的情况下，libcroco/libcroco.a
libavoid/libavoid.a
libgdl/libgdl.a
libuemf/libuemf.a
libcola/libcola.a
inkgc/libinkgc.a
libvpsc/libvpsc.a
livarot/libvarot.a
2geom/lib2geom.a
libdepixelize/libdepixelize.a
util/libutil.a
libinkversion.a
被内部库拉入（可能是automake，它被libpng15.so / libcroco拉入了），而libgtkmm是外部库的请求，我使用libcairomm对其进行了仔细维护。
Slackware是一个以libpng16.so为中心的发行版，仅保持了libpng16领域的最低水平。因此，我定期尝试分别更新该部分。对于像Qt这样的移动目标，这并不总是那么容易。另一方面，我为解决该问题所做的所有搜索都显示出一个相当大的人口，同时出现了同样的问题，其中大多数根本没有使用GTK，甚至根本没有使用Slackware-current。
当然，解决方案是重新编译-current，Slackware和其他两个静态库，然后重新编译libcairomm。
事后看来，对最终链接命令中的库列表进行简单检查将使该问题得到警告，并显示其中包含两个不同版本的libgtkmm。另一方面，这是一个非常特殊的情况，因为版本名称不同但功能相同，这是非常独特的。很抱歉，发布时间过长-希望对其他有类似问题的人有所帮助。