Hello folks,

The default dmd.conf settings for 64-bit environments include the -fPIC flag (for good reason), but the settings for 32-bit environments do not.  Any particular reason for this?

Thanks & best wishes,

    -- Joe

On Saturday, 8 April 2017 at 21:31:31 UTC, Joseph Rushton Wakeling wrote:
> Hello folks,
>
> The default dmd.conf settings for 64-bit environments include the -fPIC flag (for good reason), but the settings for 32-bit environments do not.  Any particular reason for this?
>
> Thanks & best wishes,
>
>     -- Joe

32 bit modes support for PIC is painful because the RIP relative addressing mode does not exist. AMD introduced it when they added 64 bit support in the Opteron processors. In 32 bit mode it was possible to generate PIC code but it required some ugly hacks (CALL 0) which broke some hardware optimization (the return address target cache) and adds a layer of indirection for shared libraries (GOT), which had the consequence of breaking the sharing, i.e. .so and .dll weren't really shared in 32 bit mode.
Here an in depth article that I haven't yet read but seem to be interesting on the subject https://www.technovelty.org/c/position-independent-code-and-x86-64-libraries.html
Of course, this has nothing to do with D per se.

On Saturday, 8 April 2017 at 21:31:31 UTC, Joseph Rushton Wakeling wrote:
> Hello folks,
>
> The default dmd.conf settings for 64-bit environments include the -fPIC flag (for good reason), but the settings for 32-bit environments do not.  Any particular reason for this?
>
> Thanks & best wishes,
>
>     -- Joe

And here an article explaining the difference between PIC on 32bit and 64 bit code

http://www.bailopan.net/blog/?p=50

On Sunday, 9 April 2017 at 07:12:51 UTC, Patrick Schluter wrote:
> 32 bit modes support for PIC is painful because the RIP relative addressing mode does not exist. AMD introduced it when they added 64 bit support in the Opteron processors. In 32 bit mode it was possible to generate PIC code but it required some ugly hacks (CALL 0) which broke some hardware optimization (the return address target cache) and adds a layer of indirection for shared libraries (GOT), which had the consequence of breaking the sharing, i.e. .so and .dll weren't really shared in 32 bit mode.
> Here an in depth article that I haven't yet read but seem to be interesting on the subject https://www.technovelty.org/c/position-independent-code-and-x86-64-libraries.html
> Of course, this has nothing to do with D per se.

Thanks for the explanation.  TBH I find myself wondering whether `-fPIC` should be in the flags defined in dmd.conf _at all_ (even for 64-bit environments); surely that should be on request of individual project builds ... ?

On Sunday, 9 April 2017 at 09:23:07 UTC, Joseph Rushton Wakeling wrote:
>
> Thanks for the explanation.  TBH I find myself wondering whether `-fPIC` should be in the flags defined in dmd.conf _at all_ (even for 64-bit environments); surely that should be on request of individual project builds ... ?

It's needed in order to compile working executables on debain & ubuntu.

b/c of PIE.