1

以下は、私の問題を説明する例です。

ld -Lpath1 -Lpath2 -lA -lB -Xlinker -T -Xlinker \
    -W1,-rpath,/usr/local/lib -l-o target
ld: cannot find -lA
collect2: ld returned 2 exit status

path1 と path2 は両方とも相対パスであり、ld の pwd に従ってライブラリ A を見つけることができるのに、なぜ ld はこのエラー メッセージを出力したのでしょうか?

この問題をデバッグするための提案を誰かに教えてもらえますか?

rt というライブラリの前に「-static」があります。

あなたの提案として、私はgccにldを駆動させてリンクプロセスを実行させようとしています。gcc Ao Bo -mabi=64 -static -lrt -Xlinker -T -Xlinker ld.script -W1,-rpath,/usr/local/lib -lmemdbg -o target 動作しません。

次に、「-static」オプションを削除し、-lpthread の後に別の動的ライブラリを削除します (rt は、「-static」を削除したときに検出される pthread に依存するため)

gcc Ao Bo -mabi=64 -lrt -lpthread -Xlinker -T -Xlinker ld.script -W1,-rpath,/usr/local/lib -lmemdbg -o target を実行すると、オブジェクトは正常にリンクされます。

そして、「-v」を gcc に渡して、「-static」コマンドが機能しない理由を理解しようとします。いくつかの「-L」オプションが表示され、検索リストに librt.a という名前のライブラリが見つかりました。

私は本当に混乱しました。gcc のバージョンは 4.3 です

4

1 に答える 1

1

要因となる可能性のあるさまざまな問題があります。

  • お探しの名前は何ですか？ path1/libA.a? path1/libA.so?
  • -W1オプションはおそらく であるはずです-Wlが、それではリンク エラーが説明されません。
  • -l-oオプションは、オプションの引数を持つ 2 つのオプションである必要があります-l(実際にライブラリlib-o.aまたはがある場合を除きますlib-o.so)。
  • 通常、独自に考案した少なくとも 1 つのオブジェクト ファイルを指定します。Lex/Yacc ライブラリ (私が知っている) だけが を提供しmain()ます。これは、Linux システムではなく、従来の Unix でのみ提供されます。
  • ライブラリファイルが存在すると思われる場所に存在する場合、それらは正しいタイプですか? つまり、32 ビット プログラムをビルドしている場合、それらは 64 ビット ライブラリである可能性がありますか? またはその逆でしょうか? それらはあなたのハードウェア用ですか？（通常、リンカーは「見つかりません」よりも適切なことを言うと思いますが、これは問題になる可能性があります。）
  • ライブラリ ファイルとディレクトリのアクセス許可を確認しましたか?
  • ローダーを直接呼び出すのではなく、コンパイラを使用してローダーを呼び出す方がよいでしょうか? 私の経験では、コンパイラーはローダーを正しく呼び出すことについて私よりも多くのことを知っていますld。代わりにコンパイラーを使用する場合よりも、共有オブジェクトを直接使用する場合に、より多くの人々が共有オブジェクトの構築を悲しむのを見てきました。
于 2010-07-29T02:53:51.457 に答える