Eclipse/CDT cannot debug application with linked d

I have two C++ projects in Eclipse, "amp" and "amp_auditions"

The first creates a library, C:\Users\Jared\EclipseWorkspace\amp\Debug\libamp.dll

The second, a test program ('C:\Users\Jared\EclipseWorkspace\amp_auditions'), depends on the first, and has the directory C:\Users\Jared\EclipseWorkspace\amp\Debug listed under Project Properties > Library Dependencies

To use the amp library I created, I thought all I needed to do was link the library file and include the headers, but apparently it isn't that simple.

Everything compiles, but when I go to debug, the application immediately terminates. The GDB trace tells me:

488,262 19^error,msg="During startup program exited with code 0xc0000135."

If I run the test program directly in a terminal, it complains about missing dependencies. If I place the libamp.dll file in the C:\Users\Jared\EclipseWorkspace\amp_auditions directory, everything works just fine. This tells me it is an issue where the debugger can't find libamp.dll

What did I miss? Why won't my test program run within the Eclipse debug perspective?

gcc -v

COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=c:/mingw/bin/../libexec/gcc/mingw32/4.6.2/lto-wrapper.exe
Target: mingw32
Configured with: ../gcc-4.6.2/configure --enable-languages=c,c++,ada,fortran,objc,obj-c++ --disable-sjlj-exceptions --with-dwarf2 --enable-shared --enable-libgomp --disable-win32-registry --enable-libstdcxx-debug --enable-version-specific-runtime-libs --build=mingw32 --prefix=/mingw
Thread model: win32
gcc version 4.6.2 (GCC)

gdb trace:

487,988 2-environment-cd C:/Users/Jared/EclipseWorkspace/amp_auditions
487,991 2^done
487,991 (gdb) 
487,991 3-gdb-set breakpoint pending on
487,991 3^done
487,991 (gdb) 
487,992 4-gdb-set detach-on-fork on
487,992 4^done
487,992 (gdb) 
487,992 5-enable-pretty-printing
487,992 5^done
487,992 (gdb) 
487,992 6-gdb-set python print-stack none
487,993 6^done
487,993 (gdb) 
487,993 7-gdb-set print object on
488,003 7^done
488,003 (gdb) 
488,004 8-gdb-set print sevenbit-strings on
488,005 8^done
488,005 (gdb) 
488,005 9-gdb-set host-charset UTF-8
488,005 9^done
488,006 (gdb) 
488,006 10-gdb-set target-charset WINDOWS-1252
488,016 10^done
488,016 (gdb) 
488,017 11-gdb-set target-wide-charset UTF-16
488,017 11^done
488,017 (gdb) 
488,017 12source .gdbinit
488,027 &"source .gdbinit\n"
488,027 &".gdbinit: No such file or directory.\n"
488,027 12^error,msg=".gdbinit: No such file or directory."
488,027 (gdb) 
488,028 13-gdb-set target-async off
488,028 13^done
488,028 (gdb) 
488,029 14-gdb-set auto-solib-add on
488,029 14^done
488,029 (gdb) 
488,029 15-gdb-set solib-search-path C:\\Users\\Jared\\EclipseWorkspace\\amp\\Debug
488,029 15^done
488,029 (gdb) 
488,031 16-file-exec-and-symbols --thread-group i1 C:/Users/Jared/EclipseWorkspace/amp_auditions/Deb\
ug/amp_auditions.exe
488,065 16^done
488,065 (gdb) 
488,067 17-break-insert --thread-group i1 -t -f main
488,134 18-list-thread-groups
488,167 17^done,bkpt={number="1",type="breakpoint",disp="del",enabled="y",addr="0x004013ad",func="ma\
in()",file="..\\src\\amp_auditions.cpp",fullname="C:\\Users\\Jared\\EclipseWorkspace\\amp_auditions\\
\src\\amp_auditions.cpp",line="14",times="0",original-location="main"}
488,167 (gdb) 
488,167 18^done,groups=[{id="i1",type="process",executable="C:\\Users\\Jared\\EclipseWorkspace\\amp_\
auditions\\Debug\\amp_auditions.exe"}]
488,168 (gdb) 
488,172 19-exec-run --thread-group i1
488,205 =thread-group-started,id="i1",pid="3220"
488,205 =thread-created,id="1",group-id="i1"
488,205 ~"[New Thread 3220.0xa8c]\n"
488,205 19^running
488,205 *running,thread-id="all"
488,205 (gdb) 
488,206 20-list-thread-groups --available
488,260 =thread-exited,id="1",group-id="i1"
488,261 =thread-group-exited,id="i1"
488,262 19^error,msg="During startup program exited with code 0xc0000135."
488,262 (gdb) 
488,262 20^error,msg="Can not fetch data now."
488,263 (gdb) 
488,270 21-gdb-exit
488,293 21^exit

回答1:

My understanding of the problem is that this has nothing to do with eclipse. A .dll is linked dynamically, at runtime. This means that your running application must find the library (.dll) in the system path or in the running executable folder.

A solution to your immediate problem would be to add the directory where the .dll is compiled to your Windows path variable.

回答2:

You build your test application and DLL to different folders. There's no way EXE will know where DLL is. The typical solutions are:

Build to the same folder, such as 'Bin'
Copy the DLL as a post-build step.

回答3:

Another option is to add the paths to your dlls to the LD_LIBRARY_PATH
In the debug configuration in Eclipse (Right click your project, debug as, debug configuration) click on the Environment tab. Click the New... button and put

Name:  LD_LIBRARY_PATH
Value: put the absolute path to your dll here. Separate multiple paths with a ";"

On Mac OS X its called DYLD_LIBRARY_PATH
On Linux based system you can define the variable temporarily in the same command like this:

bash$ LD_LIBRARY_PATH=/path/to/libs ./executable

I'm not sure how to do this in windows.
Double check to see if the path to your libraries is correct!

回答4:

Another easy option is to configure the Run->Debug Configurations in eclipse: There, expand the C/C++ Application, select your Debug application, then in the right-hand "Debugger" tab click on the "Shared Libraries" tab and add the paths to your shared libraries.

回答5:

For other looking for a solution:

The run configuration allows you set a PATH. Here you can add your own settings without modifying the system environment (yet). I tend to forget this at times and run into the exact same problem you described. Adding the path here solves the issue.