Cmake executable build shows up as "shared library" on Linux Mint

I’ve just tried out a Linux build of a standalone plugin (via CMake) on a Linux Mint installation. It does not seem to recognise it as an application, but seems to be a “shared library”. Is this something anyone has come across before?

I’m running cmake followed by make using GCC 8.4 on Debian to build.

IIRC, this is not specific to CMake. See

Skimming the other thread, this looks like something that we probably don’t want to change in JUCE.

Building with Clang rather than GCC seems to work around the issue, so that might be worth trying. If you need to stick with GCC, you could also try adding -no-pie to your target_compile_options.


FWIW I ended up switching to Clang. -no-pie didn’t work. There’d been some other stumbling blocks to building with GCC, better to be dealing with 2 different compilers than 3!

what shows the file utility on this binary?
I have no problems with g++ builds of JUCE plugins, for example:

file /usr/bin/CHOWTapeModel
/usr/bin/CHOWTapeModel: ELF 64-bit LSB pie executable, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/, BuildID[sha1]=00f6c587bc84f14b8be1030f23c0aafc230410cc, for GNU/Linux 3.2.0, not stripped

on Debian:
`:~/dvp$ gcc -v
Using built-in specs.
Target: x86_64-linux-gnu
Configured with: …/src/configure -v --with-pkgversion=‘Debian 10.2.1-6’ --with-bugurl=file:///usr/share/doc/gcc-10/README.Bugs --enable-languages=c,ada,c++,go,brig,d,fortran,objc,obj-c++,m2 --prefix=/usr --with-gcc-major-version-only --program-suffix=-10 --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-plugin --enable-default-pie --with-system-zlib --enable-libphobos-checking=release --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-10-Km9U7s/gcc-10-10.2.1/debian/tmp-nvptx/usr,amdgcn-amdhsa=/build/gcc-10-Km9U7s/gcc-10-10.2.1/debian/tmp-gcn/usr,hsa --without-cuda-driver --enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=x86_64-linux-gnu --with-build-config=bootstrap-lto-lean --enable-link-mutex
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 10.2.1 20210110 (Debian 10.2.1-6)

:~/dvp$ gcc keyapp.c -lX11 -o keyapp
:~/dvp$ file ./keyapp
./keyapp: ELF 64-bit LSB pie executable, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/, BuildID[sha1]=5dd628caf86a1e4d3572a5b23a6f1616490647d0, for GNU/Linux 3.2.0, not stripped

:~/dvp$ gcc -no-pie keyapp.c -lX11 -o keyappnopie
:~/dvp$ file ./keyappnopie
./keyappnopie: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/, BuildID[sha1]=3ee744a74535b7cc5c330660fa7056bf61a62952, for GNU/Linux 3.2.0, not stripped
:~/dvp$ `

both are executable; only keyappnopie can be start from desktop Gnome
Capture d’écran de 2021-04-17 12-07-22

It is not JUCE concern but a bug in Nautilus

In second to solve the problem for JUCE app with GCC

and the result

Capture d’écran de 2021-04-17 12-37-47

1 Like

Thanks, I think the issue was that I needed -fno-pie in my compiler flags.

In any case, switching to Clang makes sense to reduce the friction of supporting different compilers for the same project.