| 1 |
Hi all, |
| 2 |
|
| 3 |
Working on the fasm ebuild, have some questions: |
| 4 |
|
| 5 |
1. fasm is written on itself and has two variants: self-contained binary |
| 6 |
for x86 and amd64 and linked with libc only for x86. Also, there are |
| 7 |
tools for working with the proprietary symbolic information format which |
| 8 |
is libc-linked and only x86. So, I provide two USEs, fail in pkg_setup |
| 9 |
if we on amd64 host and hasn't multilib profile if they are set and link |
| 10 |
it with default CC with -m32. Not sure it's a 'clean' way, would be |
| 11 |
happy to get some clarification about handling such cases. |
| 12 |
|
| 13 |
2. When running my ebuild, got two warnings: one about text relocations, |
| 14 |
other about executable stack. Second problem seems trivial, just apply |
| 15 |
patches which adds corresponding ELF sections. But the first one is not |
| 16 |
clear: I found that TEXTRELs occurs due to default '--pie' option passed |
| 17 |
to ld by gcc and seems like it isn't possible to remove default ld |
| 18 |
options (only add to), so I can construct ld commandline for linking |
| 19 |
with libc manually and resolve a bunch of corner cases... But is |
| 20 |
avoiding TEXTRELs in assembly programs really necessary? Performance |
| 21 |
issues in case of assembly-written assembler seems negligible... What's |
| 22 |
best according to ::gentoo policies? |
| 23 |
|
| 24 |
See ebuild draft in attachment. |
Archives