Codelite compile executable problem.

[coder99]

Had to clean up some of my code from Codelite trials, but following your advice, I was eventually able to build samples outside of Codlite.

arnold@CarboMint:~/wx/wx-3.1.7/udb3/samples/html/helpview$ file ./helpview
./helpview: ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, BuildID[sha1]=396665645733e17485f08207b356406df948e7ad, for GNU/Linux 3.2.0, with debug_info, not stripped
arnold@CarboMint:~/wx/wx-3.1.7/udb3/samples/html/helpview$ cd ../about/
arnold@CarboMint:~/wx/wx-3.1.7/udb3/samples/html/about$ file ./about
./about: ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, BuildID[sha1]=8fa91533c8e20bcf37a4a0304ebcba854d1dd62e, for GNU/Linux 3.2.0, with debug_info, not stripped

both helpview & about throw up the "unknown file type' dialog if I try to execute them from Nemo, but both seem to run OK from Dolphin.

[DavidGH]

So it's something on your system, not something in your CodeLite settings

FWIW, this is the output on debian of doing g++ -v:

Code: Select all

 g++ -v
Using built-in specs.
COLLECT_GCC=/usr/bin/g++
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/8/lto-wrapper
OFFLOAD_TARGET_NAMES=nvptx-none
OFFLOAD_TARGET_DEFAULT=1
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Debian 8.3.0-6' --with-bugurl=file:///usr/share/doc/gcc-8/README.Bugs --enable-languages=c,ada,c++,go,brig,d,fortran,objc,obj-c++ --prefix=/usr --with-gcc-major-version-only --program-suffix=-8 --program-prefix=x86_64-linux-gnu- --enable-shared --enable-linker-build-id --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --libdir=/usr/lib --enable-nls --enable-bootstrap --enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes --with-default-libstdcxx-abi=new --enable-gnu-unique-object --disable-vtable-verify --enable-libmpx --enable-plugin --enable-default-pie --with-system-zlib --with-target-system-zlib --enable-objc-gc=auto --enable-multiarch --disable-werror --with-arch-32=i686 --with-abi=m64 --with-multilib-list=m32,m64,mx32 --enable-multilib --with-tune=generic --enable-offload-targets=nvptx-none --without-cuda-driver --enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=x86_64-linux-gnu
Thread model: posix
gcc version 8.3.0 (Debian 8.3.0-6) 

Is yours significantly different? e.g. doesn't do --enable-default-pie

[coder99]

Can't spot any significant differences, but then .......

Mine gives me:

Code: Select all

arnold@CarboMint:~/wx/wx-3.1.7/udb3/utils$ g++ -v
Using built-in specs.
COLLECT_GCC=g++
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/9/lto-wrapper
OFFLOAD_TARGET_NAMES=nvptx-none:hsa
OFFLOAD_TARGET_DEFAULT=1
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Ubuntu 9.4.0-1ubuntu1~20.04.1' --with-bugurl=file:///usr/share/doc/gcc-9/README.Bugs --enable-languages=c,ada,c++,go,brig,d,fortran,objc,obj-c++,gm2 --prefix=/usr --with-gcc-major-version-only --program-suffix=-9 --program-prefix=x86_64-linux-gnu- --enable-shared --enable-linker-build-id --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --libdir=/usr/lib --enable-nls --enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes --with-default-libstdcxx-abi=new --enable-gnu-unique-object --disable-vtable-verify --enable-plugin --enable-default-pie --with-system-zlib --with-target-system-zlib=auto --enable-objc-gc=auto --enable-multiarch --disable-werror --with-arch-32=i686 --with-abi=m64 --with-multilib-list=m32,m64,mx32 --enable-multilib --with-tune=generic --enable-offload-targets=nvptx-none=/build/gcc-9-Av3uEd/gcc-9-9.4.0/debian/tmp-nvptx/usr,hsa --without-cuda-driver --enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=x86_64-linux-gnu
Thread model: posix
gcc version 9.4.0 (Ubuntu 9.4.0-1ubuntu1~20.04.1) 
arnold@CarboMint:~/wx/wx-3.1.7/udb3/utils$ 

[DavidGH]

After reading this link I finally understand what's happening, and it's not exciting. Some recent versions of 'file' have a bug that make it falsely report executables as LSB shared objects.

I've checked that this is the case here: I took a standard executable, that's recognised as such by debian's 'file' command; testing it in a Mint 20.3 virtualbox guest, 'file' called it an LSB shared object. So it's nothing to worry about

But nobody told Nemo...

[coder99]

That sort of change to gcc would have a long list of ripple effects and will take a fair bit of work to clean them all up
One of my early interests was file identification - in the M$ world and way back then I did have a look at the Linux file command.
But that was years ago with M$ and now .... I suppose there will be a few more 'surprises' ahead.

Thank you very much for helping me clear up this mystery.

Perhaps I should move to a different distribution - more 'mainstream and up-to-date?

I picked Mint because it was recommended for immigrants from Windows, but I have used so many different OSes by now, that I'm certain, I would adapt well enough.

Any recommendation(s)?

[DavidGH]

Perhaps I should move to a different distribution - more 'mainstream and up-to-date?

That's up to you, but Mint is #3 in the Distrowatch page-hit ranking (which doesn't equate to popularity, but gives you a feel...) and is likely soon to update to follow the latest ubuntu, 22.04.

I just tested 'file' in ubuntu 22.04: it gives the correct answer.