On 2021-04-22 21:23, Sam James wrote:
Such pkg_setups are best avoided if possible because they can be
confusing and we have other tools to handle it, so I’m glad you asked!
I’d provide a USE flag for this tool and mask it on non-multilib amd64
profiles (or mask everywhere and unmask on the multilib amd64
profiles).
Fasm itself can be built and run in pure amd64 environment, so we need
to mask only USEs for building additional tools and building fasm itself
against libc in non-multilib amd64 (native x86 is correct platform too)
it this approach.
1) The TEXTREL QA warning primarily exists because of the security
issues associated with them - they prevent PIC.
The following links may be useful:
-
https://flameeyes.blog/2016/01/16/textrels-text-relocations-and-their-impact-on-hardening-techniques/
- https://wiki.gentoo.org/wiki/Hardened/Textrels_Guide
However, I think it’s not really likely to be a real world issue if
the program in question is an assembler. You’re just going to hit
possible portability issues
but I’m not sure what the details are there.
Seems like gcc when used as linker frontend expects PIE-aware code in
object file and pass '-pie' to linker, but fasm doesn't know anything
about PIE, so ld fallbacks to TEXTRELs, AFAIK. Suggest two approaches:
disable passing PIE in gcc in some way or ignore textrel issues. Manual
linking seems to be error-prone in any non-standard configuration, such
as ${ROOT}/${SYSROOT} cross-environments, binary hosts, etc... maybe I
too scared because not so familiar with linking, however.
2) Passing -fno-PIE and friends should work if you use append-* from
flag-o-matic.eclass?
Passing -fno-pie to gcc has no effect, `strace --string-limit -vfe
execve` shows that '--pie' is passed to ld anyway.
Can’t see it here.
Looks like it accidentaly not posted by my stupid webmail client, posted
in plaintext in reply to original post.
