(動的に読み込まれた)共有ライブラリを使用したプロジェクトがあり、それをデバッグしようとしています。次のエラーメッセージが表示されます。
No source file named /home/username/Code/path/to/project/MyFile.cpp.
他のスレッドを検索した後、-gを使用してコンパイルしていること、および適切なフォルダーがデバッグ構成のソースパスタブにあることを確認しました。奇妙な部分は、それが正しい絶対パスを与えているということです。それが参照するファイルは存在するので、なぜそこにあるとは思わないのかわかりません。
誰もがこれについて何をすべきか知っていますか?
同じ問題が発生しましたが、ブレークポイントは共有ライブラリではなく実行可能ファイル自体にありました。これを解決するには、「デバッグ構成」を開き、デバッグ構成を選択して、次の設定を調整する必要がありました。
共有ライブラリのブレークポイントの場合、 Eclipse cdtとgdbを使用したデバッグ からの追加情報(特に遅延ブレークポイントについて)が必要になる場合があります。 Eclipse cdtがブレークポイントを無視する理由 。
注:これは、Eclipse Kepler(4.3)およびgdb 7.4を指します。
私も同じ問題を抱えていましたが、私の場合は私のせいでした。一部のプロジェクトはリリース構成に設定されており、デバッガーは当然ソースファイル情報を見つけることができませんでした。
私も同じ問題を抱えていました。プログラムとは別の場所でコンパイルされた共有ライブラリファイル(.so)にブレークポイントを設定できませんでした。これを修正するには:
このディレクトリを毎回追加する必要がないように、将来および過去のすべてのデバッグ構成に対してこの変更を行う方法を理解していませんが、それがわかった場合は後で更新しようとします。
これは、cygwinとmingw(またはその他の変種)の両方がある場合に発生する可能性があります。 cygwinからのgccを使用してソースをコンパイルする場合、実行可能ファイルにcygwinパスがあります。次に、デバッガがmingwからのものである場合、gdbはcygwinパスを解釈できません。これを解決する最も簡単な方法は、[実行]-> [デバッグ構成]-> [デバッガ]に移動し、cygwin gdb(C:\ cygwin64\bin\gdb.exe)へのフルパスを設定することです。これで問題は解決しました。
@Andreas Festerのコメントを[Debug Configurations]設定の[Debugger]タブで追跡しましたが、「Debugger:gdb/mi」が見つかりませんが、[Source]タブですべての項目を削除し、[Add]をクリックして[Absolute File Path]を追加しました。ウィンドウの右側にある「」ボタン。それはこの問題で私を助けました
私は同じ問題を抱えていましたが、私の解決策は異なっていました。プロジェクトの "debug/src" + "release/src"ディレクトリを開き、[filename] .dファイルに、名前を変更した可能性がある、または存在しないソースファイルの名前が含まれていないことを確認します。私はそれを持っていて、それを削除しました。
したがって、少なくとも私の場合は、スコープ外のオブジェクトによってエラーが作成されたと考えます。