I am running Debian Testing and I think I have run into the recent fPIC issue.  This is the source code for the test project I am using:

import std.stdio;

void main()
{
	writeln("Edit source/app.d to start your project.");
	readln();
}


When I try to compile a project, I get the following errors (truncated for brevity):


/usr/bin/ld: /usr/lib/gcc/x86_64-linux-gnu/6/../../../x86_64-linux-gnu/libphobos2.a(thread_26c_155.o): relocation R_X86_64_32 against symbol `__dmd_personality_v0' can not be used when making a shared object; recompile with -fPIC
/usr/bin/ld: final link failed: Nonrepresentable section on output
collect2: error: ld returned 1 exit status
dmd failed with exit code 1.
Exit code 2
Build complete -- 1 error, 0 warnings

I followed the advice to add "-defaultlib=libphobos2.so -fPIC" to my dmd.conf file as a workaround.

This causes it to build without errors, but now the resulting executable is marked as a shared library:

Output of the file command:

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

Is this a known issue with this workaround or is there some other setting that I need to change?

Took me a while to replicate your build environment but it looks like a false alarm.

rikki@debian:/tmp/test$ dmd test.d
rikki@debian:/tmp/test$ file test
test: ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, for GNU/Linux 2.6.32, BuildID[sha1]=0a6394b9ec9b82e07440ab62cd71932f0ab568d1, not stripped

rikki@debian:/tmp/test$ ./test
Edit source/app.d to start your project.

rikki@debian:/tmp/test$ cat /etc/dmd.conf
;
; dmd.conf file for dmd
;
; dmd will look for dmd.conf in the following sequence of directories:
;   - current working directory
;   - directory specified by the HOME environment variable
;   - directory dmd resides in
;   - /etc directory
;
; Names enclosed by %% are searched for in the existing environment and inserted
;
; The special name %@P% is replaced with the path to this file
;

[Environment32]
DFLAGS=-I/usr/include/dmd/phobos -I/usr/include/dmd/druntime/import -L-L/usr/lib/i386-linux-gnu -L--export-dynamic -fPIC -defaultlib=libphobos2.so

[Environment64]
DFLAGS=-I/usr/include/dmd/phobos -I/usr/include/dmd/druntime/import -L-L/usr/lib/x86_64-linux-gnu -L--export-dynamic -fPIC -defaultlib=libphobos2.so

On Thursday, 3 November 2016 at 06:11:48 UTC, rikki cattermole wrote:
> Took me a while to replicate your build environment but it looks like a false alarm.
>
> rikki@debian:/tmp/test$ dmd test.d
> rikki@debian:/tmp/test$ file test
> test: ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, for GNU/Linux 2.6.32, BuildID[sha1]=0a6394b9ec9b82e07440ab62cd71932f0ab568d1, not stripped
>
> rikki@debian:/tmp/test$ ./test
> Edit source/app.d to start your project.
>
> rikki@debian:/tmp/test$ cat /etc/dmd.conf
> ;
> ; dmd.conf file for dmd
> ;
> ; dmd will look for dmd.conf in the following sequence of directories:
> ;   - current working directory
> ;   - directory specified by the HOME environment variable
> ;   - directory dmd resides in
> ;   - /etc directory
> ;
> ; Names enclosed by %% are searched for in the existing environment and inserted
> ;
> ; The special name %@P% is replaced with the path to this file
> ;
>
> [Environment32]
> DFLAGS=-I/usr/include/dmd/phobos -I/usr/include/dmd/druntime/import -L-L/usr/lib/i386-linux-gnu -L--export-dynamic -fPIC -defaultlib=libphobos2.so
>
> [Environment64]
> DFLAGS=-I/usr/include/dmd/phobos -I/usr/include/dmd/druntime/import -L-L/usr/lib/x86_64-linux-gnu -L--export-dynamic -fPIC -defaultlib=libphobos2.so

Thanks for looking at it and confirming you are seeing the same thing.

I am no expert, but after some additional research I think I see what is going on.  From what I read the gcc -fPIC option creates a shared library, while gcc -fPIE option creates an executable.  You can also create a dual purpose file that is a shared library and is also executable by creating a shared library if that file also contains a main function (that might be oversimplified a little bit).

Looking at the dmd documentation, it only has a -fPIC option, there is no -fPIE option, which has the following description:

generate Position Independent Code (which is used for building shared libraries).

So, if I am understanding everything correctly because dmd only has -fPIC, the only option is to create a dual purpose file that is both a shared library and executable.

On Thursday, 3 November 2016 at 06:11:48 UTC, rikki cattermole wrote:
> [Environment32]
> DFLAGS=-I/usr/include/dmd/phobos -I/usr/include/dmd/druntime/import -L-L/usr/lib/i386-linux-gnu -L--export-dynamic -fPIC -defaultlib=libphobos2.so
>
> [Environment64]
> DFLAGS=-I/usr/include/dmd/phobos -I/usr/include/dmd/druntime/import -L-L/usr/lib/x86_64-linux-gnu -L--export-dynamic -fPIC -defaultlib=libphobos2.so

I'm sorry bit that's horseshit. I'm not compiling everything with fPIC because DMD can't get it's act straight.

On 11/18/2016 10:35 PM, deadalnix via Digitalmars-d-learn wrote:
> On Thursday, 3 November 2016 at 06:11:48 UTC, rikki cattermole wrote:
>> [Environment32]
>> DFLAGS=-I/usr/include/dmd/phobos -I/usr/include/dmd/druntime/import -L-L/usr/lib/i386-linux-gnu -L--export-dynamic -fPIC -defaultlib=libphobos2.so
>>
>> [Environment64]
>> DFLAGS=-I/usr/include/dmd/phobos -I/usr/include/dmd/druntime/import -L-L/usr/lib/x86_64-linux-gnu -L--export-dynamic -fPIC -defaultlib=libphobos2.so
>
> I'm sorry bit that's horseshit. I'm not compiling everything with fPIC because DMD can't get it's act straight.
IIRC, LDC didn't have that problem.  I don't remember testing gdc. But, yes, it is quite annoying.

On Saturday, 19 November 2016 at 21:14:47 UTC, Charles Hixson wrote:
> [...]
> IIRC, LDC didn't have that problem.  I don't remember testing gdc. But, yes, it is quite annoying.

That's because we can maintain those compilers with the distribution and configure them appropriately to compile with hardening flags and integrate properly with the distro.
GDC is an issue here, since AFAIK it doesn't support PIC yet, so for GDC - if it works - there will be some kind of workaround in place (telling the linker to not assume PIC code, I guess).
DMD has issues because it's a 3rd-party product - ideally, the compiler should be adjusted to output PIC code by default.
You can find more information on this change at https://wiki.debian.org/Hardening/PIEByDefaultTransition

On Thursday, 3 November 2016 at 05:16:11 UTC, Dlang User wrote:
> I am running Debian Testing and I think I have run into the recent fPIC issue.  This is the source code for the test project I am using:
>
> import std.stdio;
>
> void main()
> {
> 	writeln("Edit source/app.d to start your project.");
> 	readln();
> }
>
>
> When I try to compile a project, I get the following errors (truncated for brevity):
>
>
> /usr/bin/ld: /usr/lib/gcc/x86_64-linux-gnu/6/../../../x86_64-linux-gnu/libphobos2.a(thread_26c_155.o): relocation R_X86_64_32 against symbol `__dmd_personality_v0' can not be used when making a shared object; recompile with -fPIC
> /usr/bin/ld: final link failed: Nonrepresentable section on output
> collect2: error: ld returned 1 exit status
> dmd failed with exit code 1.
> Exit code 2
> Build complete -- 1 error, 0 warnings
>

I got the same problem, still under Debian. A fix is to use these flags:

dmd -shared -m64 -fPIC -defaultlib=libphobos2.so app.d

You can also use another compiler:

dub --compiler=ldc2

or

rdmd --compiler=ldc2

Note that it is not recommended to use gdc because it is not up to date, use dmd or ldc2.

Also note, that if you use Emacs + Org Mode,

http://orgmode.org/worg/org-contrib/babel/languages/ob-doc-C.html

you will encounter the same problem. A fix is to add the following line in your .emacs file:

(setq org-babel-D-compiler "rdmd --compiler=ldc2")


Vincent