[MPlayer-dev-eng] Linking mplayer fails

[Xidorn Quan]

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?

-- 
Xidorn Quan
GnuPG fingerprint: 6F1E DF9A D250 7505 63E2  345E 7570 8D3F 7C9A 1209