[MPlayer-dev-eng] Linking mplayer fails

[Reimar Döffinger]

On 1 Apr 2013, at 17:26, Xidorn Quan <quanxunzhen at gmail.com> wrote:

> On Mon, Apr 1, 2013 at 9:02 PM, Reimar Döffinger
> <Reimar.Doeffinger at gmx.de>wrote:
> 
>> On 1 Apr 2013, at 14:51, Nicolas George <nicolas.george at normalesup.org>
>> wrote:
>>> Le duodi 12 germinal, an CCXXI, Reimar Döffinger a écrit :
>>>> I am not sure about any other systems, but since we do not enable PIE by
>>>> default for them it should't matter much.
>>> 
>>> Hum:
>>> 
>>> r35083 | reimar | Build as relocatable PIE binary by default on x86.
>>> r35094 | reimar | Disable building as PIE binary by default.
>>> r35953 | reimar | Enable auto-detection of PIE linking again.
>>> 
>>> Currently, it seems that PIE is enabled by default. I have no idea what
>> are
>>> the benefits and drawbacks in mplayer's case, but I suppose at some point
>>> someone will need to make a decision, document it and stick to it.
>> 
>> It greatly hinders exploits, which I think is quite a benefit,
>> particularly when it costs almost nothing.
>> 
>>> Also, if PIC is required with PIE, then moving the PIC test before PIE
>> seems
>>> wrong, so I suggest to start by reverting r36098.
>> 
>> Wish it was so simple. PIE requires PIC on x86-64, but PIC has almost no
>> cost, so it's ok.
>> PIE does not require PIC on x86-32, and PIC has a very high cost there, so
>> it should not be enabled unnecessarily there.
>> But I think the compiler is supposed to figure that out, so I agree that
>> that commit probably should be reverted, it seems like it is actually a bug
>> in clang, and if necessary we should work around it without breaking PIE
>> everywhere else.
>> 
> 
> If the relationship between PIE, PIC and the system arch is as simple
> as what you said, why not do the detection together directly, so that
> we will not need to rely on the compilers' decision?

Simple? I listed two architectures with three different behaviours (I forgot about hardened configs on x86-32), how many does gcc support? 50? I'm not crazy enough to try this madness of coding them all in even for the few we officially support.
Hardcoding the broken compilers is certainly going to be easier, though we'd need more information since I've compiled MPlayer just fine on OSX with both gcc and clang.