Code::blocks and x/shared-lib app


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

Code::Blocks and LinuxMakefile build as x-shared-library

This is also the case for the Linux Makefile. Therefore I set “-no-pie” by hand, too.


Thanks for the info. I was finally able to build an executable that can be clicked in the GUI file manager to run it! Shouldn’t this be made the default for the Linux makefiles for standalone apps…?


Am I confusing something here: normally, the suggestion is to always use position independent code on Linux (-fpie) as you need this to link to any shared library on linux. I can’t see how this would effect launching the linux executable from the gui anyway.


As far as I know, -fpie is recommended. However, linking this way leads to an executable that actually looks like a shared object from the outside:
file ./Projucer
Projucer: ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/, for GNU/Linux 3.2.0, BuildID[sha1]=89bc03b81be414a614ee3b00232ac2d220d7d3d8, not stripped
This binary is executable from the command line (./Projucer), but gui file managers seem to have a problem with this.
Linking with no-pie leads to the normal executable:
file ./Projucer
./Projucer: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/, for GNU/Linux 3.2.0, BuildID[sha1]=fd444f477376f54db1d2b4021d684cda4c63aec2, not stripped
No idea what the best practice might be here…


It’s Linux, does more need to be said? :smiley:

But more seriously : the defaults that Projucer generates into the makefile produce a shared object even when building a standalone application. This causes at least the Ubuntu GUI file manager to refuse to launch the app. If -no-pie is added to the linker flags, the resulting binary will be an executable that the file manager does launch. These can be confirmed from the command line using the “file” program. Perhaps it’s really about something else than the -no-pie flag, but at least setting that does seem to work.


There must be something odd with your build system. Compiling the Projucer on a fresh clone of JUCE on a fresh install of Ubuntu gives me this:

./Projucer: ELF 64-bit LSB executable, x86-64, version 1 (GNU/Linux), dynamically linked, interpreter /lib64/, for GNU/Linux 2.6.32, BuildID[sha1]=d96df5ac0f3aa3e3215c1c31b8fa9818ccee18e7, not stripped


My gcc 7.2. installation was by default configured with --enable-default-pie (checked with gcc -v), which has been added some time ago. Maybe --enable-default-pie is the reason for the difference?
Clang btw. gives the same type of shared object executable for me.


What Linux distribution are you using?

On Ubuntu 16 LTS with -fPIE explicitly added to everything, clang 3.8.0-2ubuntu4 and gcc 5.4.0-6ubuntu1~16.04.5 both produce normal executables.


I’m using Arch Linux, with a gcc 7.2.0 and clang 5.0.0.
If I remember correctly, when I was using gcc 5 (configured without --enable-default-pie), I got normal executables without the need for - no-pie.


I can reproduce the issue with gcc 7.2.0 on the latest Ubuntu (but not with clang 5.0.0).

However, I’d like to have a grumble before I “fix” things.

The fault here lies with the GUI file managers which are probably misinterpreting the (misleading!) output of file - see this post in a related bug report for more details. So that leaves us in the position where we have to either rely on both GUI file browsers fixing this bug and Linux distributions updating their packages, or automatically make all JUCE GUI apps less safe. Not a nice place to be in.


an interesting article

d) Why do I need “-pie” aside from “-fPIE” when building pie executable?


Ah, that makes more sense now! Recompiling more carefully with PIE using the older compilers on my Ubuntu 16 LTS distribution I get ELF 64-bit LSB shared object too.



I’ve just undone the change above. Older versions of clang and more exotic compilers throw an error when they encounter the -no-pie linker flag, and detecting the type and version of the compiler at compile time is not feasible across all the exporters we support.

Ultimately the maintainers of the GUI file browsers and compiler packages for each platform will have to fight it out. In the mean time having all this information in this thread will help visibility of the problem.