“No source file named” error debugging Eclipse CDT

Question

I've got a project with a shared library (loaded dynamically), and I'm attempting to debug it. I get the following error message:

No source file named /home/username/Code/path/to/project/MyFile.cpp.

After having searched other threads, I've ensured that I'm compiling with -g, and that the appropriate folders are on the source paths tab of debug configurations. The strange part is that it's giving the correct absolute path: the file it references does exist, so I don't understand why it doesn't think it's there.

Anyone know what to do about this?

Answer 1

for Makefile project existing code. step 1 check compile all the sources with -g -o0 step 2 use the gdbserver and arm-yourversion-gdb which will be provided in your sdk and gdb toolchain.

Answer 2

I had the same problem, but in my case it was my fault. Some of my projects were set to Release configuration and the debugger naturally could not find the source file information.

Answer 3

I had the same problem. I couldn't set a breakpoint in a shared library file (.so), compiled in a different place than my program. To fix this:

1. Go to the Debug Configuration, Source tab
2. Add a compilation directory (I used the location of the main makefile that compiles all processes, not where the makefile for this process is located).
3. also click "Subdirectories are also used for compilation" (my subprocess makefile is compiled in a subdirectory of the main location)

I haven't figured out how to make this change for all debug configurations future and past so that I don't have to add this directory every time, but I'll try to update later if I do figure that out.

Answer 4

This can happen if you have both cygwin and mingw (or some other variant). If gcc from cygwin is used to compile the source you'll have cygwin path in executable. Then, if the debugger is from mingw, gdb will not be able to interpret the cygwin path. The easiest way to solve this is to go to Run -> Debug Configurations -> Debugger and set full path to cygwin gdb (C:\cygwin64\bin\gdb.exe). That solved the problem for me.

Answer 5

I just came across the same issue, although my breakpoints were in the executable itself, not in a shared library. To solve this, I had to open the "Debug configuration", select my debug configuration and adjust the following settings:

• At the bottom, there is a link "Select other ..." to select the Create Process launcher. Click the link. Tick the "Use configuration specific settings". Select "Standard Create Process Launcher" and press "Ok".
• Go to the "Debugger" tab, and on the top of the tab select "Debugger: gdb/mi". What may/may not make a difference: On the same tab there is also a checkbox "Use full file path to set breakpoints" - I played with this, but it does not seem to affect the issue we observe (obviously, our source paths are already full paths).

For breakpoints in shared libraries, you might need additional information (especially about deferred breakpoints) from Debugging with eclipse cdt and gdb and Why does eclipse cdt ignore breakpoints.

Note: This refers to Eclipse Kepler (4.3) and gdb 7.4.

Answer 6

I had the same problem but my solution was different. Open up the project "debug/src" + "release/src" directories and ensure that there are no [filename].d files that contain the name of any source files that may have changed their names or that no longer exist. I had one, deleted it, and since no more errors.

I would therefore presume, at least in my case, that the errors are created by objects that have fallen out of scope.