Executable running while it should not (Nightly - Windows)

[jeancf]

Hi,

I am trying to understand the behaviour of C::B with the app that I am currently working on. I compiled and dynamically linked my .exe with a library that is not on the system PATH nor in the current directory and yet, when I start the app from the IDE, it runs instead of complaining that it can't find the DLL.

myapp.exe is in C:\dev\myproject\bin
mylibrary.dll is in C:\dev\some_library\lib

When I try to run the app from the command line though, I get the expected error message.

I searched the configuration screens of C::B and my project but I could not find any explanation of why it is doing this but I would prefer to disable that behaviour if possible.

Thanks,

/~jc

[mandrav]

I searched the configuration screens of C::B and my project but I could not find any explanation of why it is doing this but I would prefer to disable that behaviour if possible.

The linker search paths are used in PATH (for windows), LD_LIBRARY_PATH (for linux) and DYLD_LIBRARY_PATH (for mac) when you run your program.
This is (IMO) a nice feature and I must say I 'm surprised that you want this disabled. It's only there to make you (development) life a little easier.

[jeancf]

Thanks for your reply.

I suspected something like that.

I now checked under Linux (gentoo) and it does not work. When I launch the app from C::B it does not run and terminates with status -1.

Actually I think it is a helpful feature but I am a little confused by its inconsistent behaviour and I think I would like to have some sort of control on it (enable/disable).

[mandrav]

Thanks for your reply.

I suspected something like that.

I now checked under Linux (gentoo) and it does not work. When I launch the app from C::B it does not run and terminates with status -1.

Actually I think it is a helpful feature but I am a little confused by its inconsistent behaviour and I think I would like to have some sort of control on it (enable/disable).

In linux it doesn't work when running through cb_console_runner (e.g. your target is set as "Console application"). I 'm still investigating why that is...

[jeancf]

In linux it doesn't work when running through cb_console_runner (e.g. your target is set as "Console application")

My application is a wxWidgets app. In linux the target type for my project is set to GUI Application.

[mandrav]

In linux it doesn't work when running through cb_console_runner (e.g. your target is set as "Console application")

My application is a wxWidgets app. In linux the target type for my project is set to GUI Application.

The linker search paths are used in PATH (for windows), LD_LIBRARY_PATH (for linux) and DYLD_LIBRARY_PATH (for mac) when you run your program.

wx-config --libs does not (yet) qualify as a search path, except for the compiler itself .
If you want this to work now, just add manually the path containing the .so in linker search paths (last).

[jeancf]

I understand now. Thanks a lot for the clarification.

/~jc

[jeancf]

Hang on a second... the DLL that is not found is not a wxGTK DLL linked through wx-config as you assumed. It is actually the wxsqlite3 DLL, the PATH of which is listed in the linker search paths. The only peculiar thing about it is that the path is based on a custom variable $(WXSQLITE3_DIR)\lib. Would that be the reason?

[mandrav]

Hang on a second... the DLL that is not found is not a wxGTK DLL linked through wx-config as you assumed. It is actually the wxsqlite3 DLL, the PATH of which is listed in the linker search paths. The only peculiar thing about it is that the path is based on a custom variable $(WXSQLITE3_DIR)\lib. Would that be the reason?

No, it shouldn't be a problem: variables' substitution is performed as normal. But maybe we have a problem with the backslash there. Can you replace it with a slash and see if it works?

You have confused me though: you mentioned you were trying this in linux and now you 're mentioning dlls?!?

[jeancf]

I am confusing indeed. After a week of going back and forth between windows and Linux I start mixing things up :?

In short:

• Under windowsC::B behaves as you describe.
• Under Linux, my project is set up as a GUI Application type, the wxGTK libraries are linked through invocation of wx-config and the wxsqlite3 library is linked through $(WXSQLITE3_DIR)/lib in the linker search paths. The app compiles fine but when launched from C::B it does not run and exits with status -1. If I add the path where my library resides to LD_LIBRARY_PATH then the app runs fine.

I  hope this clarifies the situation.

/~jc

[mandrav]

I am confusing indeed. After a week of going back and forth between windows and Linux I start mixing things up :?

In short:

• Under windowsC::B behaves as you describe.
• Under Linux, my project is set up as a GUI Application type, the wxGTK libraries are linked through invocation of wx-config and the wxsqlite3 library is linked through $(WXSQLITE3_DIR)/lib in the linker search paths. The app compiles fine but when launched from C::B it does not run and exits with status -1. If I add the path where my library resides to LD_LIBRARY_PATH then the app runs fine.

I  hope this clarifies the situation.

/~jc

I can't reproduce this and I think my project uses variables in linker paths too. Anyway, have you tried replacing the $(WXSQLITE_DIR) variable with its real value? Maybe this can give me a hint where to look.

[jeancf]

I followed your suggestion and replaced the variable by the real path. It worked and the app ran. Then I went back to the path based on the variable and... it worked as well :?

Everything seems to be behaving as expected now. I am sorry for wasting your time on this.

Many thanks,

/~jc