Re: [gentoo-dev] Re: [gentoo-commits] repo/gentoo:master commit in: media-libs/x265/

[Mike Gilbert]

On Tue, May 26, 2020 at 2:13 PM Mike Gilbert <floppym@g.o> wrote:
>
> On Tue, May 26, 2020 at 2:03 PM Alexis Ballier <aballier@g.o> wrote:
> >
> > On Tue, 26 May 2020 10:45:39 -0400
> > Mike Gilbert <floppym@g.o> wrote:
> > > > Note that having the 'pic' useflag should be considered something
> > > > to be fixed: rewrite the asm in a PIC way. But these days nobody
> > > > has the will to do it since this is mostly an issue on x86+pax,
> > > > both being slowly decreasing.
> > >
> > > Given that PaX has been stripped out of official Gentoo kernels due to
> > > the grsecurity licensing issue, I wonder if there is any other good
> > > reason to keep the "pic" USE flag today. Surely this affects a very
> > > small population of users.
> >
> >
> > I couldn't find any recent reference, but PIC shared libs used to be a
> > QA policy. There's mainly two reasons to it: First is W^X enforcement;
> > non PIC shared libs are refused by the x86_64 linker so a non-issue
> > there, on x86 you need pax to emulate it because the mmu doesn't support
> > the X part; I don't know about other arches.
> > Then there is the small memory waste done because those libs will be
> > loaded COW and thus their "code" is not shared anymore between
> > processes. And the small startup performance hit to
> > perform the relocations.
> >
> > The latter part affects everyone, and the rule of thumb for having a
> > pic useflag (instead of always pic) is that the gain for non-pic asm is
> > better than the loss of non-pic shared libs. This is subjective but
> > usually a no-brainer for multimedia packages.
>
> Assuming that the pic performance penalty is really only relevant on
> legacy arches (like x86), here are a couple of options:
>
> 1. Disable pic on arches where tie performance penalty is small.
> 2. Force pic everywhere, performance be damned.

Option 1 should say "Disable pic on arches where the performance
penalty is large."