On 12/04/2017 05:39 PM, Andreas K. Huettel wrote: > Am Montag, 4. Dezember 2017, 03:58:40 CET schrieb tu...@posteo.de: >> Hi, >> >> what could fail, when doing the change to PIE-enabled applications >> on base of the regular updates? >> Compilation may fail, if libs are included and not flagged as to be >> recompiled, which are of the "old standard"... >> What else can fail? What may be the worst scenario? > The worst case scenario is that you spend too much time worrying about it. > > Some devs including me switched profile without rebuilding anything outside > the normal updates. (Because the guidelines were not written up yet.) > Things just kept working fine. > > What can go wrong is that you get random build failures at some point later > (likely with a linker message about failed relocations). These indicate that > the linker was instructed to combine PIE and non-PIE code, which doesnt work. > So one of the involved packages has not been rebuilt yet and needs to be > rebuilt. This is mostly happening when static libraries are involved. > Question :
Quote from the eselect news item : "Switching the profile from 13.0 to 17.0 modifies the settings of GCC 6 to generate PIE executables by default; thus, you need to do the rebuilds even if you have already used GCC 6 beforehand. If you do not follow these steps you may get spurious build failures when the linker tries unsuccessfully to combine non-PIE and PIE code." Does this mean that a "package" with no USE flag of PIE / PIC will be built with the gcc switches " -fpic / -fPIE " applied? Or is this the equivalent of putting the " PIE / PIC " USE flags in make.conf? Corbin