User:Sam/ISA markers vs startup files
Rough notes because I keep putting off writing something up on this.
Problem
Users report that building programs with -march=x86-64 (e.g. a trivial Hello World program) on a machine that is otherwise built with -march=x86-64-v4 won't run on "weaker" machines like e.g. the x86-64 baseline, as ld.so reports "CPU ISA level is lower than required".
An example of such a user is https://bugs.gentoo.org/927298#c3 but it happened on IRC a few times too.
Why now
In 1f0fd3e2aee01e0c09e7103c8af4183b57faef49 (in gentoo.git), we dropped workarounds that disabled the multiarch + ISA marker parts of glibc.
Inspection showed glibc startup files were tainted even though they contained no vector (or other) special instructions (i.e. ld had added the x86-64-v4 ISA marker).
(I don't recall if we've seen a case involving GCC target libraries, but that might just be because they hit glibc first, of course.)
Fixes
Not clear what the best solution is. The status quo is very confusing for users.
- For glibc, AFAIK building such startup files with any interesting -march is useless. We can use
--with-rtld-early-cflags
.- amonakov notes that we really want
--with-nonshared-cflags
. - H.J.'s glibc commit 46c999741340ea559784c20a45077955b50aca43 raises a question: does fixing the startup files mean that glibc doesn't check this otherwise? I assume ld.so will for other libraries but this needs checking.
- amonakov notes that we really want
- For gcc, is it as clear-cut for target libraries?
- This likely got worse with bb2d045c02a6ca647ef3280f4987cbc0d14e5a7e (in gentoo.git) which made us build target libraries with user *FLAGS by setting *_FOR_TARGET