C::B creates a shared lib instead of an app under Kubuntu

[PeterP]

hi,
I'm not sure if this is a problem with Linux (Kubuntu) or C::B...
I used C::B for many years under Windows and never had a problem...
but now under Kubuntu I have this problem...

I create a GUI application (although it doesn't matter the problem also occures with console apps)...
inside C::B everything works fine, as expected...
but when I go to the folder where the created file is located the file is not an app, but a shared lib !!!
and I can't run it outside C::B unless I use XTerm to run it...

for illustration I made a Youtube video: https://www.youtube.com/watch?v=AzFZ6uqaTDw

Kubuntu and Code::Blocks are the latest versions and updates...

what could be the problem and how can I solve it

thanks

[stahta01]

Post a full rebuild log.

http://wiki.codeblocks.org/index.php/FAQ-Compiling_(errors)#Q:_How_do_I_troubleshoot_a_compiler_problem.3F

[BlueHazzard]

It would also be good to post a "ls -la" output from the folder where the executable is.

[PeterP]

here is the build log

Code

-------------- Clean: Release in test-fltk (compiler: GNU GCC Compiler)---------------

Cleaned "test-fltk - Release"

-------------- Build: Release in test-fltk (compiler: GNU GCC Compiler)---------------

g++ -I/usr/local/include -I/usr/local/include/FL/images -D_THREAD_SAFE -D_REENTRANT -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -O2 -s -I/usr/local/include -I/home/acki/Libs/cTools -I/home/acki/Libs/cTools/XMLDoc/include -c /home/acki/Source/test2/main.cpp -o ./obj/Release/main.o
g++ -I/usr/local/include -I/usr/local/include/FL/images -D_THREAD_SAFE -D_REENTRANT -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -O2 -s -I/usr/local/include -I/home/acki/Libs/cTools -I/home/acki/Libs/cTools/XMLDoc/include -c /home/acki/Source/test2/window.cpp -o ./obj/Release/window.o
g++ -L/usr/local/lib -L/home/acki/Libs/cTools/XMLDoc -o ./bin/test-fltk ./obj/Release/main.o ./obj/Release/window.o   -lfltk -lm -lX11 -lXext -lXinerama -lXfixes -lXft -lXrender -lfontconfig -ldl -lfltk_forms -lfltk_gl -lfltk_images -lfltk_jpeg -lXMLDoc
Output file is ./bin/test-fltk with size 914.76 KB
Process terminated with status 0 (0 minute(s), 1 second(s))
0 error(s), 0 warning(s) (0 minute(s), 1 second(s))

and a screenshot of the output from ls -la

[cacb]

I saw a similar problem after installing Kubuntu 17.04. I don't think it is caused by Code::Blocks, but gcc.

Check if you can run your application from a terminal, it should start just fine. Then if you are unable to run the same program by clicking on it in Dolphin, you are most likely looking at this problem:

GCC compiles programs to shared object instead of executable, preventing GUI file managers from executing programs
https://bugs.launchpad.net/ubuntu/+source/shared-mime-info/+bug/1639531

[PeterP]

I saw a similar problem after installing Kubuntu 17.04. I don't think it is caused by Code::Blocks, but gcc.

Check if you can run your application from a terminal, it should start just fine. Then if you are unable to run the same program by clicking on it in Dolphin, you are most likely looking at this problem:

GCC compiles programs to shared object instead of executable, preventing GUI file managers from executing programs
https://bugs.launchpad.net/ubuntu/+source/shared-mime-info/+bug/1639531

yes, exactly the problem I encounter...
so this is the wrong forum for this...
but maybe you know a solution

thanks

[cacb]

but maybe you know a solution

First of all it is not unique to Kubuntu or KDE, but any Linux desktop I think. The problem is that gcc generates PIE (Position Independent Executable) code, which the file browsers believe is shared object files, and therefore they will not run them when a user clicks on the file.  It looks like nobody takes responsibility to solve this annoying problem. But I did implement my own work-around. I created a file

Code

~/.local/share/applications/RunExec.desktop

With the contents:

Code

[Desktop Entry]
Exec=%f
MimeType=application/x-sharedlib;
Name=RunExec
NoDisplay=true
Type=Application

Essentially it fools KDE to run the program when clicking on it, even if it thinks it is a shared library. Now, if it really is a shared library, you will get an error which is fine.

Once they get this issue sorted out, we should just delete ~/.local/share/applications/RunExec.desktop

[PeterP]

thanks cabc !!!
works like a charm !!!

I hope they'll get it sorted out...

it's still strange to run a "shared lib" that actually is an application !!!