Emerging fpc on amd64 with FEATURES="strict stricter" fails with QA concerns about executable stacks Reproducible: Always Steps to Reproduce: 1.FEATURES="strict stricter" ACCEPT_KEYWORDS="~amd64" emerge fpc 2. 3. Actual Results: Emerge fails Expected Results: emerge finishes successfully
Created attachment 157993 [details] Output log of scanelf
I would be happy to try to patch fpc to mark the generated object files as not requiring executable stacks, but I'm not sure there are no cases where they do. George, do you know?
Sorry, I am not really versed on hardened :(. For Ada it was Kevin Quinn who did all related stuff, although in the end there were issues with backend and trampolines (don't ask) so we ended up pax-marking stuff to avoid warnings. See any of the later gnat-gxx ebuilds for how this was done. Plus a few lines in gnatbuild.eclass (basically just inherit pax-utils and pax-mark E $(find ${GNATBOOT} -name gnat1) But this is just a workaround rather than fix..
I have asked upstream, and fpc itself does not use or generate any dynamic code, and lazarus does not do so either anymore. However, other libraries do. Because of that, if fpc's behaviour changes, a new compiler option will need to be added to keep it possible to mark the stack as executable, and compiler options is surely not an area in which it is good to diverge from upstream. I have opened a report there, and I suggest we leave fpc as is for now, that we wait for a newer version that will fix this.
