I recently upgraded my Linux OS and installed DMD 2.098. But now when I build my project with Dub, I can't run the binary by clicking the binary's icon because the OS thinks it is a shared library. I can still run it from the command line though.

I read that this might be fixed by not using -fPIE, so I removed that flag from dmd.conf. But then my program won't even compile.

On Wednesday, 27 October 2021 at 03:39:53 UTC, Elronnd wrote:>
On Wednesday, 27 October 2021 at 03:39:53 UTC, Elronnd wrote:

My project is a game (using graphics). I've set all the necessary fields in dub.json. I can run it from the command line which opens the window and starts the game correctly. But it will not run when started from the gui by clicking on the icon.

The output from the "file" command shows that the OS thinks this is a shared object. (see below)

ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, BuildID[sha1]=7956a95c2464895f9b02c1dab1b11961a69f56f4, for GNU/Linux 3.2.0, not stripped

I even created a Makefile and compiled it with make/dmd and I get the same result. Is this a Linux-specific issue when compiling with the -fPIC option (set in dmd.conf). And is it possible to compile a project using dmd without the -fPIC option?

I tried to remove -fPIC from dmd.conf, but it fails with the below message:

_relocation R_X86_64_32 against symbol `_dmd_personality_v0' can not be used when making a PIE object; recompile with -fPIE
collect2: error: ld returned 1 exit status

This only started happening when I upgraded my Linux and DMD versions, so I assume it's a recent change in one of those.

On Tuesday, 26 October 2021 at 15:13:02 UTC, Stephen C wrote:

This is not a problem with your D toolchain, it's a problem with whatever graphical interface you're using to view the file and click on it. Which Linux distribution are you using, and which file browser/desktop environment are you using when you attempt to run the program by clicking on it?

On Wednesday, 27 October 2021 at 19:16:29 UTC, Paul Backus wrote:

Linux Mint 20.2 with XFCE4 and Thunar file manager.
I think you're right - it seems to be a problem with Thunar (and possibly other file managers in Linux).

From a bug report I just found:
An application built with the "-PIE" flag will be seen as a "application/x-sharedlib" mime type unless the user explicitly uses the "-nopie" link flag. When attempting to open the application, Thunar will ask the user what application to use - even though it's an application.

I assume this also happens with the "-PIC" flag. But is there any way to run DMD without the -fPIC flag (set in dmd.conf)? I tried to remove it, but then it won't compile at all.

On Wednesday, 27 October 2021 at 19:48:14 UTC, Stephen C wrote:

I have the same issue on Debian with PCManFM. A bit of searching turns up this bug report for the shared-mime-info database, which seems to be the root of the problem:

https://gitlab.freedesktop.org/xdg/shared-mime-info/-/issues/11

Since Debian 9, pretty much all Debian-based distros have their C toolchain set up to produce position-independent executables by default. So you will probably need to have DMD pass -no-pie when it invokes GCC to link the executable (or do a separate link step and pass it yourself).

On Wednesday, 27 October 2021 at 22:09:26 UTC, Paul Backus wrote:

I just wanted to post that this worked. Running DMD with the "-v" flag showed exactly how it uses CC to link. I was able to compile with DMD and then add the "-no-pie" flag to the CC linker command and it works perfectly now - the binary is tagged as "executable" and can now be run by clicking it's icon in the GUI.

Thanks, Paul.