fredag 21 oktober 2011 15.25.54 skrev  Duncan:
> Mike Frysinger posted on Fri, 21 Oct 2011 08:13:22 -0400 as excerpted:
> > On Thursday 20 October 2011 23:20:35 Duncan wrote:
> >> Magnus G suggests possibly adding PIE to amd64, which is already PIC,
> > 
> > this isn't quite right.  amd64 shared objects (i.e. libraries) are PIC.
> > the applications are not.
> 
> Thanks for the correction.  I knew the library think but supposed that
> was the difference between PIC/PIE, the E/executable for executables
> only, the more generic C/code for the feature applied to shared objects.
> 
> Seems there's a bit more to it than that.  Thanks again, I can look it up
> now that I know to do so.
> 
> > usually these packages are multimedia related.  like ffmpeg iirc.  so i
> > think the impact is much greater than your estimate here.
>
I don't have any probs with ffmpeg. We disable the asm stuff only for x86 and
not amd64 and that is the case on alot of the multimedia related packages.
Most problem we have now is the packages in app-emulation

> I figured mm, but also assumed strip-flags-like exceptions (probably
> controlled via USE flag) for packages where the default was really
> costly.  But now that I think of it, implementing that as arch defaults
> while allowing overrides isn't quite the simple matter it is for user-set
> CFLAGS, etc, and strip-flags, etc.
We allready use pic USE flag, filter-flags -fPIE or gcc-specs-pie to disable 
or do stuff so the package works.

> 
> I assume it can still be done, but am not in a position to estimate
> whether it'd be worth the cost to implement.
> 
> >> What about x32, tho?  Does it get PIC by default too
> > 
> > x32 is same as x86_64 wrt PIC
> 
> Good to know.  Thanks.

/Magnus