Cannot run a program compiled in Code Blocks ouside Code Blocks

[Radek]

I have a project under development which is in "almost usable" stage. When I add a new feature, I create a "release build" and copy it outside the project folder. Until now, the build behaved as expected and I was happy. Perhaps with the rev. 8500, the programs built in Code Blocks do not run outside Code Blocks any more. Symptoms:

- Inside Code Blocks, the program runs as expected.
- Copying the executable outside Codeblocks, double click - nothing happens.
- Trying to run from the command line. The executable is marked as executable in the "ls" listing. Running. Getting "bash: no such command".
- Trying the same with the "original" in the bin/Release and bin/Debug folders of the project. The same result.
- Checking access rights. Okay.
- Playing with the command completion TAB. It lists some applications starting with 'v' but not the 'viewer'.
- Running ClamAV. Only known "viruses" found. ClamAV marks encrypted PDFs as infected. The amount of "viruses" agrees, the "infected files" agree as well.
- Searching Code Blocks forum. Nothing usable has been found.

The executable seems to be linked somehow incorrectly. Code Blocks is able to run it but the operating system itself isn't for some unknown reason. The executable does not seem to be recognized as an executable. The problem is new, perhaps from the latest nighty build. The last "almost usable" build made with the previous version of Code Blocks worked for sure.

32-bit Debian 6, Code Blocks rev. 8500, Gnome.

[oBFusCATed]

Does using something like "./myprogram" works?

[Jenna]

That's for sure not a C::B error.
Can you provide a minimal projetrc, where it same happens ?

What does a simple console-project do ?

[Radek]

I have recompiled a trivial console program which seems to run from the command prompt. At least, I haven't got the "command not found" frown. I recompiled another simple program which uses wxwidgets, like the not working "viewer" - and it does not run as well. The same symptom: "command not found". The problem seems to be related to wxwidgets projects.

On my comp: wxWidgets 2.8.12, shared library build, release build, downloaded as a package from a repository. It used to work all the time.

./viever crashes on GP fault (the segmentation fault).

[Jenna]

If you run from commandline and the exe is not in the systems search path you need to specify the relative path.
If your are in the folder where the exe resides you need to run it with ./exename, otherwise you getthe error you described.
If the program segfaults when you run it this way, you either have a "real" programming error, or the program is linked against unusual libs, which are not found by the system, but are specified in the search path of your project, so it is used when running from inside C::B, but not from commandline (just a possible error).

[ouch]

Also be sure your user has permission to actually launch executables in that folder.

[Radek]

The current directory is always on the search path.
You need "./app" if the "app" is an "executable script" which will be run by something else known to the system. For example "./configure".
The only unusual libs used by the app are wxwidgets libs. wxwidgets is installed in /usr/lib so that it should be found.
AFAIK, there is no permission for running apps in a particular folder in Debian. There are "owner", "group" and "others" permissions.

If it were a general problem the the problem would be here all the time but it isn't.

[Jenna]

The current directory is always on the search path.

Not on linux !
At least not on the linuxes I use.
This is a security feature.

You always need to run an app with [relative_or_absolute_path_to]/exefile .
Did you try it and it also does not work, or did you even not try it.
If it's the second, I stop answering in this thread, because if you do not want any help, it's not worth to spend my time.

[Radek]

I made some experiments:

(1) Copying file-roller (a windowing app) in a folder in my /home
- running by double-click : runs
- running from commandline as "file-roller" : runs
- running from commandline as "./file-roller" : runs
- running fom Midnight Commander by double-click : runs

(2) compiling a "hello world" app (a commandline app, only a "printf") named "test" in Code Blocks and copying in a folder in my /home
- running from Code Blocks : runs
- running by double-click : nothing happens (expected)
- running from commandline as "test" : runs but does not produce the output
- running from commandline as "./test" : runs and writes "hello world"
- running from Midnight Commander by double-click : opens a command window, runs and writes "hello world"

(3) copying the problematic app "viewer" (a windowing app) in a folder in my /home
- running from Code Blocks : runs
- running by double-click : nothing happens
- running from commandline as "viewer" : command not found
- running from commandline as "./viewer" : GP fault
- running from Midnight Commander : nothing happens

So, you need not write "./" in Debian for executables nor run executables only from "standard places". I have tried not only "./" but also specifying the full path (/home/radek/db/viewer), creating a launcher and assigning /home/radek/db/viewer to it (I got "cannot run a child"). I also tried to run "ldd" and "elfread" on the "viewer" and I got the expected output. No complaints that this is not an executable. Still, "command not found" or a GP fault.

There must something happen to linking an app in Code Blocks in the last version. Some strange binding or requesting.

[MortenMacFly]

There must something happen to linking an app in Code Blocks in the last version. Some strange binding or requesting.

Inspect the full build log and you'll see exactly what's going on. There is no hidden magic, never has been nor will be.

BTW: don't use "test" as application name on Unixes. This is a reserved system command. Surely you get different results if you call that by accident, i.e. w./the local prefix "./".

[Radek]

Good hit, Morten. I renamed "test" to "zzz" and I got:

- running as "zzz" : command not found
- running as "./zzz" : runs and writes hello world

So the seemingly running "test" run something else. Full logging is turned on. Command line:

g++ -Wall -fexceptions -O2 -std=c++0x include dirs -c source file -o object file
g++ -o object file -s

Errata: not Midnight Commander but Gnome Commander

[Radek]

My deep apologies. The problem was related to my stupidity, not to Code Blocks 

What happened? The application is XRC based. During development, a new dialog has been added to the app. The XRC changed, but only in the project folder of the app. The place, where I run the app outside the IDE, contained an old version of the XRC. So, the application run like charm in Code Blocks but once it was copied ouside the IDE, it did not find the dialog in the XRC, all XRCCTRL returned NULL, NULL pointers got dereferenced immediately, and a GP fault followed.

Copying the valid XRC solved all problems. viewer now runs on double click.