5

Ubuntu PPA の ktorrent を最新のアップストリーム バージョンにアップグレードしようとしています。また、更新された libktorrent パッケージも必要です。libktorrent が互換性のない方法で変更されたため、以前に利用可能だった libktorrent4 の代わりに新しいパッケージ libktorrent5 が作成されたようです。

ただし、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では、このプロセスは「symbols」ファイルの助けを借りて自動化されます（または自動化できます）。たとえば、アプリをパッケージ化する場合、パッケージ化プロセス（正確には、dpkg-shlibdeps）は、アプリがどのライブラリからインポートするシンボルをチェックし、library-packageのsymbol-fileとクロスチェックして、必要なライブラリの見積もりを取得します。 -バージョン。

パッケージにはすでにシンボルファイルが含まれているようです（良いです！）

あなたがしなければならない唯一のことは、あなたがすでに持っている情報に基づいて、このファイルを更新することです。ビルドログのdiff-outputを実際のシンボルファイルと比較し、シンボルファイルに適切な行を追加することにより、これを手動で行う必要があります。

例（新しい記号の追加）

たとえば、ビルドログに次のような行が含まれていると想像してください。

+ _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~（末尾のチルダはそのままにします）

例（シンボルの削除）

残念ながら、得られる出力は、ライブラリからいくつかのシンボルが削除されたことを示しています。互換性が損なわれるため、これは悪いことです。（アプリケーション（のみ）dht::FindNodeRsp::~FindNodeRsp()がバージョン1.0.3で導入され、バージョン2.3.0で削除されたシンボルを使用している場合は、バージョン1.0.3に対してリンクできますが、バージョン1.2.5を使用することもできます。このシンボル。アプリは、ライブラリに存在するかどうかに関係なく、他のシンボルを処理しません）。

互換性が失われるため、最初に確認する必要があるのは、library-packagenameのメジャーバージョン番号を上げることです。

たとえば、ライブラリが（アップストリーム）リリース「1.0.3」と「1.0.4」の間のシンボルを削除し、元の（バイナリ）パッケージ名が「libfoo1」（アップストリーム「1.0.3」のパッケージ化に使用）だった場合、 （バイナリ）パッケージ名を「libfoo2」に変更する必要があります（アップストリームバージョンはまだ1.somethingですが）

これはMUSTであり、Debianポリシーによって規定されています！

バイナリパッケージ名の名前を変更します。ほとんどの場合、シンボルファイルの名前をからdebian/libfoo1.symbolsに変更する必要があります。debian/libfoo2.symbols

それが終わったら、シンボルファイルから問題のある行を削除します。

アーキテクチャの問題：32ビットと64ビット

さまざまなアーキテクチャ、特に64ビットシステムと32ビットシステムで「外観」が異なる一部のタイプで問題が発生する可能性があります。これらのタイプの最も一般的なものはです。これは、アーキテクチャに応じて、またはのsize_tいずれかに拡張できます。unsigned longunsigned int

pkgkde-gensymbols幸いなことに、これらのケース（の一部）を処理するためのツールdpkg-gensymbolsが存在します。pkg-kde-tools

これを使用するには、symbolsファイルの関連するエントリを次のように変更します（ライブラリがシンボル "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.Debian他のビルドシステム、たとえばdh「標準」の単純なKDEパッケージでそれを行う方法については、pkg-kde-toolsを参照してください。

于 2012-10-01T14:08:43.570 に答える