Generated executables appear as shared libraries

[MxDevlin]

When building a BlitzMax executable program on Linux, the generated executable is detected as a shared library and cannot be launched normally. On my current project in BMax produces this output when launching from graphical interface and produces this output when using file command.

./ees: ELF 32-bit LSB shared object, Intel 80386, version 1 (SYSV), dynamically linked, interpreter /lib/ld-linux.so.2, for GNU/Linux 2.6.32, BuildID[sha1]=bff6936bdde6b97ee3790dd6ae45d379961cd0ac, stripped

I believe there's a switch (-no-pie) that can be used in gcc to solve this issue.

[nitrologic]

There was some discussion of this on monkeycoder forum, until archive is available here is excerpt:

(13569, 82, '2018-02-09 02:35:14', '2018-02-09 02:35:14', 'I looked into the whole "shared library" executable problem.\n\n \n\nThe problem is not with Monkey, it's with newer versions of GCC using the -pie option (PIE= Position Independent Executable, a newer security feature).  Because of this, anything compiled with it will appear to Nautilus file manager as a shared library rather than an executable.  I've read through tons of bug reports and complaints about the new behavior, and Nautilus devs don't think it's their job, the GCC devs don't think it's theirs, etc..\n\nHowever, we can pass the -no-pie parameter to the linker to make "older style" executables.  I did a quick test and it worked beautifully!\n<pre class="lang:monkey decode:true ">'LD options\nMX2_LD_OPTS_LINUX= -no-pie\nMX2_LD_OPTS_LINUX_DEBUG=\nMX2_LD_OPTS_LINUX_RELEASE=-s -O3\nI added -no-pie to the MX2_LDS_OPTS in bin/env_linux.txt than ran a rebuild2go\n\nNow my executables launch as normal and even have the correct executable icon

[nitrologic]

The problem with patching this is the risk of earlier versions of gcc shitting the bed unable to comprehend -no-pie flag.

Adding following (untested) to afflicted distros may be a solution to this issue,

export BMK_LD_OPTS="-no-pie"