5

我正在尝试将我的 Ubuntu PPA 中的 ktorrent 升级到最新的上游版本。它还需要更新的 libktorrent 包。似乎 libktorrent 以不兼容的方式进行了更改，因此导致了一个新的包 libktorrent5 而不是以前可用的 libktorrent4。

但是，当我尝试在我的 PPA 上构建包时，我收到有关不同符号的错误。我尝试了一些方法来修复它，但每次都失败，输出不同。

是否有一些指导如何正确生成符号文件？

完整的构建和构建日志在这里

dh_strip debug symbol extraction: disabling for PPA build dh_strip debug symbol extraction: not doing anything since NO_PKG_MANGLE is given    dh_makeshlibs -Xusr/lib/kde4/ -a -O--parallel -O--
-O--dbg-package=libktorrent-dbg dpkg-gensymbols: warning: some new symbols appeared in the symbols file: see diff output below dpkg-gensymbols: warning: some symbols or patterns disappeared in the symbols file: see diff output below dpkg-gensymbols: warning: debian/libktorrent5/DEBIAN/symbols doesn't match completely debian/libktorrent5.symbols
--- debian/libktorrent5.symbols (libktorrent5_1.3.0-0ubuntu0~ppa4_amd64)
+++ dpkg-gensymbolsNTCQU9   2012-09-30 02:21:19.000000000 +0000 @@ -2912,13 +2912,20 @@   _ZTVN3utp9UTPServer7PrivateE@Base 1.2.0   _ZTVN3utp9UTPServerE@Base 1.2.0   _ZTVN3utp9UTPSocketE@Base 1.2.0
- _ZThn12_N2bt5UTPex5visitE14QSharedPointerINS_4PeerEE@Base 1.3.0
- _ZThn52_N3dht11FindNodeRspD0Ev@Base 1.3.0
- _ZThn52_N3dht11FindNodeRspD1Ev@Base 1.3.0
- _ZThn52_N3dht11GetPeersRspD0Ev@Base 1.3.0
- _ZThn52_N3dht11GetPeersRspD1Ev@Base 1.3.0
- _ZThn8_N2bt4Peer12chunkAllowedEj@Base 1.3.0
- _ZThn8_N2bt4Peer12handlePacketEPKhj@Base 1.3.0
+#MISSING: 1.3.0-0ubuntu0~ppa4# _ZThn12_N2bt5UTPex5visitE14QSharedPointerINS_4PeerEE@Base 1.3.0
+ _ZThn16_N2bt4Peer12chunkAllowedEj@Base 1.3.0-0ubuntu0~ppa4
+ _ZThn16_N2bt4Peer12handlePacketEPKhj@Base 1.3.0-0ubuntu0~ppa4
+ _ZThn24_N2bt5UTPex5visitE14QSharedPointerINS_4PeerEE@Base 1.3.0-0ubuntu0~ppa4
+#MISSING: 1.3.0-0ubuntu0~ppa4# _ZThn52_N3dht11FindNodeRspD0Ev@Base 1.3.0
+#MISSING: 1.3.0-0ubuntu0~ppa4# _ZThn52_N3dht11FindNodeRspD1Ev@Base 1.3.0
+#MISSING: 1.3.0-0ubuntu0~ppa4# _ZThn52_N3dht11GetPeersRspD0Ev@Base 1.3.0
+#MISSING: 1.3.0-0ubuntu0~ppa4# _ZThn52_N3dht11GetPeersRspD1Ev@Base 1.3.0
+ _ZThn80_N3dht11FindNodeRspD0Ev@Base 1.3.0-0ubuntu0~ppa4
+ _ZThn80_N3dht11FindNodeRspD1Ev@Base 1.3.0-0ubuntu0~ppa4
+ _ZThn80_N3dht11GetPeersRspD0Ev@Base 1.3.0-0ubuntu0~ppa4
+ _ZThn80_N3dht11GetPeersRspD1Ev@Base 1.3.0-0ubuntu0~ppa4
+#MISSING: 1.3.0-0ubuntu0~ppa4# _ZThn8_N2bt4Peer12chunkAllowedEj@Base 1.3.0
+#MISSING: 1.3.0-0ubuntu0~ppa4# _ZThn8_N2bt4Peer12handlePacketEPKhj@Base 1.3.0   (c++)"non-virtual thunk to bt::ChunkDownload::getStats(bt::ChunkDownloadInterface::Stats&)@Base"
1.2.0   (c++)"non-virtual thunk to bt::ChunkDownload::~ChunkDownload()@Base" 1.2.0   (c++)"non-virtual thunk to bt::DataCheckerJob::acquired()@Base" 1.2.0 dh_makeshlibs: dpkg-gensymbols -plibktorrent5 -Idebian/libktorrent5.symbols
-Pdebian/libktorrent5 -edebian/libktorrent5/usr/lib/libktorrent.so.5.0.0  returned exit code 1
4

1 回答 1

8

如果一个库发布（作为不同版本）具有不同的导出符号，则该库的任何“消费者”（即动态链接到它的每个应用程序/库）都需要跟踪它需要哪个特定版本的库。

例如，如果您的应用程序仅使用符号“dht::FindNodeRsp::FindNodeRsp()”并且该符号是在库的 0.7 版中引入的，那么您的应用程序至少需要库的 0.7 版（即使当前版本是 0.9 )

在 debian 上，这个过程是（或：可以）在“符号”文件的帮助下自动化的。例如，如果您打包您的应用程序，打包过程（准确地说：dpkg-shlibdeps）将检查您的应用程序从哪个库导入了哪些符号，并与库包的符号文件进行交叉检查以估计所需库-版本。

看来你的包已经有一个符号文件（好！）

您唯一需要做的就是根据您已有的信息更新此文件。您绝对应该手动执行此操作，方法是将构建日志中的差异输出与实际符号文件进行比较，并将适当的行添加到您的符号文件中。

示例（添加新符号）

例如，假设您的构建日志包含如下一行：

+ _ZThn52_N3dht11FindNodeRspD1Ev@Base 1.3.0

这意味着在库的版本中_ZThn52_N3dht11FindNodeRspD1Ev@Base添加了一个新符号 ( )。由于损坏的名称几乎不可读（至少对人类来说），您可能需要运行它以消除它：+1.3.0c++filt

 $ echo _ZThn52_N3dht11FindNodeRspD1Ev@Base | c++filt 
 non-virtual thunk to dht::FindNodeRsp::~FindNodeRsp()@Base

在这种情况下，您应该在符号文件中添加一个新行：

 (c++)"non-virtual thunk to dht::FindNodeRsp::~FindNodeRsp()@Base" 1.3.0

请注意，您可能应该去掉本地版本的后缀，例如1.3.0-0ubuntu0~ppa4应该成为1.3.0-0ubuntu0~（保留尾随波浪号）

示例（删除符号）

不幸的是，您得到的输出表明，许多符号已从您的库中删除。这很糟糕，因为它破坏了兼容性！（如果您的应用程序（仅）使用在 1.0.3 版中引入但在 2.3.0 版中删除的符号dht::FindNodeRsp::~FindNodeRsp()，您可以将其链接到 1.0.3 版，但您也可以使用 1.2.5 版，因为它仍然提供这个符号；您的应用程序不会关心库中可能存在或不存在的其他符号）。

因为它破坏了兼容性，所以你应该确保的第一件事是增加你的 library - packagename的主要版本号。

例如，如果您的库已删除（上游）版本“1.0.3”和“1.0.4”之间的符号，并且原始（二进制）包名称为“libfoo1”（用于打包上游“1.0.3”），那么您应该将（二进制）包名称更改为“libfoo2”（即使上游版本仍然是 1.something）

这是必须的，由 Debian 政策规定！

重命名二进制包名称，很可能涉及将符号文件重命名debian/libfoo1.symbols为debian/libfoo2.symbols

一旦你这样做了，从符号文件中删除有问题的行。

架构问题：32 位与 64 位

您可能会遇到一些在各种架构上“看起来”不同的类型的问题，特别是 64 位系统与 32 位系统。这些类型中最常见的是size_t，它可以扩展为unsigned long或unsigned int，具体取决于您的架构。

幸运的是，存在处理（某些）这些情况的工具，例如pkgkde-gensymbols替换 for dpkg-gensymbols，它附带pkg-kde-tools

要使用它，请将符号文件中的相关条目修改为如下所示（假设您的库导出符号“foo::bar(size_t n)”

  (c++|subst)"foo::bar({c++:size_t})@Base" 1.2.3

然后你必须告诉你的debian/rules文件使用pkgkde-gensymbols而不是标准。如果您使用 CDBS 进行打包，请在普通包含后添加以下行：

  include /usr/share/pkg-kde-tools/makefiles/1/cdbs/symbolshelper.mk

请参阅README.Debianpkg-kde-tools 以获取有关如何为其他构建系统执行此操作的信息，例如dh和/或“标准”简单 KDE 包。

于 2012-10-01T14:08:43.570 回答