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

**URL:** <https://forum.juce.com/t/cmake-executable-build-shows-up-as-shared-library-on-linux-mint/45503>\
**Category:** Linux\
**Created:** [April 13, 2021, 12:40pm UTC](https://forum.juce.com/t/cmake-executable-build-shows-up-as-shared-library-on-linux-mint/45503 "2021-04-13T12:40:08Z")\
**Posts on this page:** 8\
**Page:** 1

<div class="post-metadata">

**Author:** ![adamwilson](https://sea2.discourse-cdn.com/flex026/user_avatar/forum.juce.com/adamwilson/32/1387_2.png) [@adamwilson](https://forum.juce.com/u/adamwilson)\
**Post date:** [April 13, 2021, 12:40pm UTC](https://forum.juce.com/t/cmake-executable-build-shows-up-as-shared-library-on-linux-mint/45503/1 "2021-04-13T12:40:08Z")

</div>

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.

---

<div class="post-metadata">

**Author:** ![mcmartin](https://sea2.discourse-cdn.com/flex026/user_avatar/forum.juce.com/mcmartin/32/7432_2.png) [@mcmartin](https://forum.juce.com/u/mcmartin)\
**Post date:** [April 13, 2021, 2:17pm UTC](https://forum.juce.com/t/cmake-executable-build-shows-up-as-shared-library-on-linux-mint/45503/2 "2021-04-13T14:17:45Z")

</div>

IIRC, this is not specific to CMake. See

> [@Code::blocks and x/shared-lib app](https://forum.juce.com/t/code-blocks-and-x-shared-lib-app/24932):
>
> For Linusers, Projucer generates a codeblocks project without the gcc flags “-no-pie” and “-fpie” so the generated application cannot be ran on desktop or graphics file chooser (need a cmd terminal as ./my-app) the setting below

---

<div class="post-metadata">

**Author:** ![reuk](https://sea2.discourse-cdn.com/flex026/user_avatar/forum.juce.com/reuk/32/21494_2.png) [@reuk](https://forum.juce.com/u/reuk)\
**Post date:** [April 13, 2021, 3:22pm UTC](https://forum.juce.com/t/cmake-executable-build-shows-up-as-shared-library-on-linux-mint/45503/3 "2021-04-13T15:22:51Z")

</div>

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`.

---

<div class="post-metadata">

**Author:** ![adamwilson](https://sea2.discourse-cdn.com/flex026/user_avatar/forum.juce.com/adamwilson/32/1387_2.png) [@adamwilson](https://forum.juce.com/u/adamwilson)\
**Post date:** [April 14, 2021, 7:36pm UTC](https://forum.juce.com/t/cmake-executable-build-shows-up-as-shared-library-on-linux-mint/45503/4 "2021-04-14T19:36:31Z")

</div>

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!

---

<div class="post-metadata">

**Author:** ![KottVV](https://sea2.discourse-cdn.com/flex026/user_avatar/forum.juce.com/kottvv/32/14169_2.png) [@KottVV](https://forum.juce.com/u/KottVV)\
**Post date:** [April 15, 2021, 4:15am UTC](https://forum.juce.com/t/cmake-executable-build-shows-up-as-shared-library-on-linux-mint/45503/5 "2021-04-15T04:15:36Z")

</div>

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

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

```

---

<div class="post-metadata">

**Author:** ![sukoi26](https://avatars.discourse-cdn.com/v4/letter/s/8e8cbc/32.png) [@sukoi26](https://forum.juce.com/u/sukoi26)\
**Post date:** [April 17, 2021, 10:11am UTC](https://forum.juce.com/t/cmake-executable-build-shows-up-as-shared-library-on-linux-mint/45503/6 "2021-04-17T10:11:29Z")

</div>

on Debian:  
`:~/dvp$ gcc -v  
Using built-in specs.  
COLLECT\_GCC=gcc  
COLLECT\_LTO\_WRAPPER=/usr/lib/gcc/x86\_64-linux-gnu/10/lto-wrapper  
OFFLOAD\_TARGET\_NAMES=nvptx-none:amdgcn-amdhsa:hsa  
OFFLOAD\_TARGET\_DEFAULT=1  
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/ld-linux-x86-64.so.2, 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/ld-linux-x86-64.so.2, 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](https://us1.discourse-cdn.com/flex026/uploads/juce/original/2X/5/53083a1ffbbfce895f98c841f1ed0204f5605537.png)

It is not JUCE concern but a bug in Nautilus

---

<div class="post-metadata">

**Author:** ![sukoi26](https://avatars.discourse-cdn.com/v4/letter/s/8e8cbc/32.png) [@sukoi26](https://forum.juce.com/u/sukoi26)\
**Post date:** [April 17, 2021, 10:39am UTC](https://forum.juce.com/t/cmake-executable-build-shows-up-as-shared-library-on-linux-mint/45503/7 "2021-04-17T10:39:05Z")

</div>

In second to solve the problem for JUCE app with GCC

 ![Capture d’écran de 2021-04-17 12-34-44](https://us1.discourse-cdn.com/flex026/uploads/juce/original/2X/e/e4cf6b5c08577fff3ce061a43a4ddfdb6756b1d2.png)

and the result

![Capture d’écran de 2021-04-17 12-37-47](https://us1.discourse-cdn.com/flex026/uploads/juce/original/2X/a/a8d55d1a6bb949934a78269ef16bf3e18694e384.png)

---

<div class="post-metadata">

**Author:** ![adamwilson](https://sea2.discourse-cdn.com/flex026/user_avatar/forum.juce.com/adamwilson/32/1387_2.png) [@adamwilson](https://forum.juce.com/u/adamwilson)\
**Post date:** [April 18, 2021, 10:55am UTC](https://forum.juce.com/t/cmake-executable-build-shows-up-as-shared-library-on-linux-mint/45503/8 "2021-04-18T10:55:34Z")

</div>

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.
