On 5 July 2017 at 19:51, Daniel Micay firstname.lastname@example.org wrote:
On Wed, 2017-07-05 at 12:36 +0300, Evangelos Foutras wrote:
On 2 July 2017 at 19:19, Daniel Micay via arch-dev-public email@example.com wrote:
Using -fno-plt would be a nice tiny little performance boost at runtime but then it's important to make sure everything is compiled with -Wl,- z,now and there might be programs ignoring LDFLAGS but respecting CFLAGS. Ideally -z now would be the default in the linker first. If we aren't going to patch the default, then I think a configure flag for that needs to land upstream.
It's also worth noting that clang does not support the -fno-plt option and I couldn't find any discussions about adding support for it.
If it's only a tiny performance improvement, I strongly believe we should skip it for now.
There's no loss of compatibility from only some code using it. The only issue with it is that immediate binding *must* be used to support it, so if CFLAGS is respected then LDFLAGS *must* be respected, or immediate binding needs to be set as the default in the linker(s).
By lacking support I meant that clang aborts the compilation and throws an error with -fno-plt:
clang-4.0: error: unknown argument: '-fno-plt'
I briefly discussed this on IRC with Bartłomiej and he finds it acceptable to add workarounds (removing -fno-plt from CFLAGS) to the few dozen packages that use clang for building (not counting AUR packages).
I disagree and do not consider insignificant performance increases to be sufficient justification to add GCC 6+ specific options to the default CFLAGS and necessitate adding workarounds to packages that do not use the default compiler.
And then there is the (minor) issue you highlight, and possibly other issues we don't know about (since -fno-plt hasn't been adopted by any other distro).
On a related note, it is unclear to me whether you mean that packages might fail to build (and/or run?) if they only respect CFLAGS but not LDFLAGS, or that a package might fail to build (and/or run?) because one of its dependencies didn't respect LDFLAGS.