これに遭遇するのは私だけではありません。
SDK で設定された 1 つのサードパーティおよび別の静的ライブラリとリンクする必要がある C++ アプリケーションがあります。SDK は、非常に苛立たしい理由で、同じサードパーティ ライブラリのサブセットを独自の (名前が変更された) ライブラリに再コンパイルしましたが、シンボル自体は同じ名前であり、名前空間内にカプセル化されていません。私のアプリケーション自体は、同じサードパーティ ライブラリに依存しています。
いくつかのオプションを検討しましたが、何かが欠けている可能性があり、新しい外観が私を助けてくれることを願っています. おそらく私は近くにいて、誰かがこれらのいずれかの次のステップを知っているでしょう. これまでに試したことと、各ソリューションの欠点を列挙します。
両方にリンクします。約 2500 行のシンボルの再定義/サイズ変更の警告とエラーが表示されます。これは、彼らが同じシンボルを定義していることを最初に発見したときです。OpenSSL を g++ で再コンパイルして、現時点で名前空間にドロップしようとしています...以下の編集を参照してください...
SDK のみとリンクします。自分のコードが依存する未定義のシンボルを取得します。これは、サードパーティの lib の再コンパイルがサブセットであるか、少なくとも 1 つのモジュールが無効に設定されていることがわかったときです。
サードパーティのライブラリのみとリンクします。SDK によって報告された未定義のシンボルがいくつかあります。そのうちの 1 つは実際にはサード パーティ ライブラリ内のヘッダー ファイルの #define であるため、サード パーティ ライブラリ内のすべての参照は定義に解決されますが、外部の参照は解決されません。私はそれをcファイルに移動しました。これにより解決されますが、どこにも見つからない未解決の関数が2つあります。これは私がこれまでに得た中で最も近いものです。
競合するシンボルを 1 つのライブラリから削除し、両方のリンクをリンクします。これまでのところ、これは機能していません。SDK で静的にリンクされた lib と、サードパーティの lib を使用してみたバージョンとの間のバージョンの問題である可能性がありますが、一部の関数がシンボル間で移動されているように見えるため、シンボルを削除することで、うっかり削除してしまいました他の場所で必要な機能。SDK のシンボル内の関数とサードパーティ ライブラリ内のシンボル内の関数との間の完全なマッピングはないようです。アドレスを手動で調整せずに機能を削除することは妥当ですか?
私はライブラリ内のシンボルを次のように調べてきました:
nm -C --defined-only lib<name>.a
そして、オブジェクト全体を次のように抽出します:
ar -x lib<name>.a <objname>.o
うまくいけば、これは、互いに競合するサードパーティのライブラリとリンクしなければならなかった他の人にも役立つでしょう. 詳細のために、サードパーティのライブラリはOpenSSLであり、SDK はOpsecです。libcpopenssl.a は Opsec の問題のあるライブラリです。
**編集 - 遅いエントリの可能な回避策は、OpenSSL を g++ で再コンパイルし、すべてを名前空間に配置してから、両方のライブラリをリンクすることです。私は今それを試みています...もっと来る...