| 1 |
On Tue, 09 May 2017 18:13:06 -0500 |
| 2 |
Matthias Maier <tamiko@g.o> wrote: |
| 3 |
|
| 4 |
> > For a transition we can probably build everything with -fPIE but not |
| 5 |
> > link with -pie. If we want that to happen fast, gcc-6 might do that |
| 6 |
> > and gcc-7 add the -pie option. |
| 7 |
> |
| 8 |
> I am not entirely convinced that a transition period of one gcc |
| 9 |
> version is enough for a smooth transition [1]. |
| 10 |
|
| 11 |
In theory, a transition period won't help. It'll probably mitigate the |
| 12 |
user issues by a lot though. Note that by being a source based rolling |
| 13 |
distro we're quite different than e.g. fedora rebuilding all their repo |
| 14 |
at each release. |
| 15 |
|
| 16 |
[...] |
| 17 |
> Related to that |
| 18 |
> |
| 19 |
> - for which architectures shall we unmask the use flag? |
| 20 |
|
| 21 |
Keep in mind that if the performance implications are almost inexistent |
| 22 |
for amd64, pie might have serious implications on other arches. x86 |
| 23 |
eating one register for pie/pic and lacking an easy way to write pic |
| 24 |
safe asm is a very well known problematic arch. |
| 25 |
|
| 26 |
Which raises the question: What happens for multilib amd64 ? |
| 27 |
|
| 28 |
|
| 29 |
[...] |
| 30 |
> [3] The fallout I currently see due to enabled USE=pie is noticeably |
| 31 |
> but by no stretch crazy bad. After all, static linkage is rarely used |
| 32 |
> (with the exception of some languages). |
| 33 |
|
| 34 |
After only a few days in ~arch and no tinderbox run I'd say that's |
| 35 |
pretty normal :) |
| 36 |
|
| 37 |
static linkage is more present than one would like though; and it's not |
| 38 |
only -static, but also libs that do not make sense or break when shared |
| 39 |
(libfl comes to mind) |
| 40 |
|
| 41 |
|
| 42 |
Alexis. |
Archives