CodeLite IDE

Codelite 16.0.0
After successfully building & debugging the helpview sample project, I can run it inside Codelite, both in debug and release mode.
However, when I open the file location in Nemo, it lists the executable as 'shared library' and won't let me run it directly, complaining about an unknown file type.
The permissions are set to allow execution.

FWIW, I am rather new to this part of Linux/Mint/Codelite

Hi,

After successfully building & debugging the helpview sample project,

Do you mean the helpview/ part of the wxWidgets samples/html? Or something else?

Anyway, if there's disagreement about a program, the 'gold-standard' is to run it in a terminal. What happens if you do
./helpview

If that's unhelpful, what is the output of doing:
file ./helpview

Regards,

David

DavidGH wrote: ↑Wed Jun 29, 2022 1:29 pm

Do you mean the helpview/ part of the wxWidgets samples/html? Or something else?

Yes, the helpview sample; my appologies for not being more specific.
I wanted to keep my wxWidgets 3.1.7 tree clean and also practice building my own apps. Hence I copied that helpview code to some new place in my build location.

Running:
Mint:~/wx/pkg/cppWorkspace/helpview/deb$ ./helpview ../test.zip

works as expected, for both the debug & release version.

So it sounds as if it's a Nemo false-alarm, not something that you/CodeLite are doing wrong

Another illusion shattered

Curiously, though, alternate file managers also have issues.
Nautilus - same problem - no alternative offered
MC installs, but does not seem to run
Dolphin shows the same issue, but offers the option to execute the file, and when selected it runs as expected, both release and debug versions.
even Dolphin sees it as a DLL

It still makes me wonder what the real issue is and how to resolve it without having the Codelite generated code treated in such a special way

What is the output of
file ./helpview

Mine, for a wx3.0.5 gtk3 build, is

ELF 64-bit LSB pie executable, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, for GNU/Linux 3.2.0, BuildID[sha1]=db596e0bcb1fc021f1d31f8effbf3753277898b5, with debug_info, not stripped

for the debug version:
./helpview: ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, BuildID[sha1]=0426e89333fd37d185384c1b96eeec9ab32a4f14, for GNU/Linux 3.2.0, with debug_info, not stripped

./helpview: ELF 64-bit LSB shared object

Interesting. I googled for that phrase and learned something from the results, especially this and this.

IIUC the difference might be caused by our gcc default settings (I'm using debian buster, gcc 8.3.0), but I might be wrong. Could you build the helpview sample outside CodeLite, just using the wxWidgets makefile, and do 'file' again on the resulting binary. If that gives the same output it's a result of your gcc settings or similar.

OTOH if the output is different, not a 'shared object', then please paste your CodeLite project's compiler and linker settings here (and ideally provide an archive of the whole project either here or in a pastebin e.g. https://anonfiles.com/).

Unfortunately, my skills are not up to running the make process by itself. At least when I tried make -f helpview.mk helpview, I got all sorts of complaints regarding undefined references.

Adding the option -no-pie to my linker flags seems to give me the correct output and the file (file 5.38) command now gives

file ./helpview
./helpview: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, BuildID[sha1]=938db812840e2230872edb1e278ddae2f6b1efe1, for GNU/Linux 3.2.0, with debug_info, not stripped

Looks like this issue is sorted out for now.

Thank you

...At least when I tried make -f helpview.mk helpview..

You need to configure, and preferably build, wx first. The easy way (and it keeps your source dir clean) is, in the wx source dir:

(mkdir -p udb3 && cd udb3 && ../configure --with-gtk=3 --prefix=$(pwd) --enable-debug --enable-cxx11 && make -j`nproc`)

You then will have an 'in situ' GTK+3 wxWidgets build in udb3/ (and you can use it for other things by pointing to its wx-config script in that dir).

After that, you'd normally do:
cd udb3/samples/html && make -j
to build the sample, but you could do something similar inside your CodeLite project.