disable global visibility override hack (vis.h) by default
authorRich Felker <dalias@aerifal.cx>
Fri, 11 Aug 2017 04:17:00 +0000 (00:17 -0400)
committerRich Felker <dalias@aerifal.cx>
Fri, 11 Aug 2017 04:17:00 +0000 (00:17 -0400)
commitdc2f368e565c37728b0d620380b849c3a1ddd78f
tree670c8185a57f03ca9779ef87f3bb834f2799fcd8
parent947d330f68c49680dcc54439f56da2a297228962
disable global visibility override hack (vis.h) by default

neither current compilers nor linkers treat protected visibility the
way I expected, as having fixed source-level semantics rather than
being dependent on target-specific ABI details, and change seems
unlikely. while the use here does not actually depend on the specific
semantics, at least some versions of some linkers, especially lld,
refuse to allow linking to a libc.so where the symbols have protected
visibility. this cannot be detected at configure-time because linking
libc.so itself works fine, and because even if we could test linking
an application against libc.so successfully, we could not justifiably
assume that the same linker used to link libc.so would also be used
later to link applications.

disable the vis.h hack by default at the configure level, but add an
explicit "auto" option to request the old configure-time detection
rather than just removing it. this leaves it easy to evaluate whether
it actually resulted in significant size or performance benefits while
ensuring that out-of-the-box builds are not unlinkable for some users.

fortunately, preliminary evaluation suggests that at least x86_64,
arm, and aarch64 don't suffer at all from the change, and impact on
other archs is low. if low is not low enough, it should not be hard to
analyze where the significant PLT call ABI costs are present and
mitigate them without the hack.
configure