[arch-dev-public] Changing compilation flags

[Evangelos Foutras]

On 5 July 2017 at 19:51, Daniel Micay <danielmicay at gmail.com> 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
>> <arch-dev-public at archlinux.org> 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.