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
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
[image]
[image]
reuk
April 13, 2021, 3:22pm
3
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
.
2 Likes
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!
KottVV
April 15, 2021, 4:15am
5
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/ld-linux-x86-64.so.2, BuildID[sha1]=00f6c587bc84f14b8be1030f23c0aafc230410cc, for GNU/Linux 3.2.0, not stripped
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
It is not JUCE concern but a bug in Nautilus
In second to solve the problem for JUCE app with GCC
and the result
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.