Howto debug executable project with references to dynamic library project

[mavatar]

Hi,

I am new to Code Blocks and have a simple question in regards to workspaces with multiple projects. Specifically I have a workspace with two projects (I am developing on both the Windows & Ubuntu platforms):

(1) a console based executable
(2) a dynamic link library (dll / so)

The library project produces a *.a which is then used when compiling the console based executable. Everything works great until I try to run or debug the executable. The executable fails to launch because it cannot find the DLL/SO binary. This is understandable because the library binary live within a different project folder structure. This was never a problem is Visual Studio because it placed all binaries (from the same solution) into a single release/debug folder - thus allowing the normal windows DLL location finding logic to work (relative to the executable). On Linux I've always resolved this problem (when using Eclipse) by setting the LD_LIBRARY_PATH using the Eclipse environment variables feature.

What is the preferred approach to resolving this issue (for both Windows & Linux) using Code Blocks. Is the solution for Windows that I need to change my project path settings so the binaries are all put in the same debug/release folder? What about for Linux? Do I need to create my own LD_LIBRARY_PATH config file?

Has anybody run into / resolved these issues? Thanks

[ollydbg]

I haven't meet this kind of problem.(windows XP)

For me, I have build OpenCV libraries(debug version). (Both have dll files and .a files)
Then, I have build my own executable files which link to opencv libraries.
Note, the DLLs and my own executables were not in the same directory.

Then I can debug my own executable applications and step into OpenCV libraries.

[mavatar]

I think I've answered my own questions.

To resolve the shared library (dll) references at runtime I have:

1) (On Windows) changed the target output paths for all projects to point to the same folder (as Visual Studio does). The windows DLL loader always starts its search by looking in the executable folder.

2) (On Linux) I will use the -rpath linker option to force the loader to look in the current working directory.