Re: [PATCH v3 2/2] Default to --with-default-link=no (bug 25812)

[Florian Weimer <fweimer@redhat.com>]

* Dmitry V. Levin:

> On Fri, Apr 22, 2022 at 08:35:37AM +0200, Florian Weimer via Libc-alpha wrote:
>> * Siddhesh Poyarekar:
>> 
>> >> diff --git a/INSTALL b/INSTALL
>> >> index 63c022d6b9..de150f66eb 100644
>> >> --- a/INSTALL
>> >> +++ b/INSTALL
>> >> @@ -90,6 +90,12 @@ if 'CFLAGS' is specified it must enable optimization.  For example:
>> >>        library will still be usable, but functionality may be lost--for
>> >>        example, you can't build a shared libc with old binutils.
>> >>   +'--with-default-link=FLAG'
>> >> +     With '--with-default-link=yes', the GNU C Library does not use a
>> >> +     custom linker scipt for linking its individual shared objects.  The
>> >> +     default for FLAG is the opposite, 'no', because the custom linker
>> >> +     script is needed for full RELRO protection.
>> >> +
>> >
>> > Andreas' comments still apply here I think, i.e. fix the "scipt" type
>> > and rephrase so that it's clearer that the option controls the library 
>> > build process and not the library itself.
>> 
>> I thought I had fixed this.  What about this?
>> 
>> '--with-default-link=FLAG'
>>      With '--with-default-link=yes', the build system does not use a
>>      custom linker script for linking shared objects.  The default for
>>      FLAG is the opposite, 'no', because the custom linker script is
>>      needed for full RELRO protection.
>> 
>> > Does it make sense to make this --disable-custom-link or
>> > --enable-default-link instead, since the option is binary?  The --with 
>> > prefix is typically for richer options, e.g. paths.  Suggest something
>> > like this:
>> >
>> > --disable-custom-link
>> >     Don't use a custom linker script to build the GNU C Library,
>> >     preferring the static linker's default script instead.  The custom
>> >     linker script is needed for full RELRO protection.
>> 
>> I want to backport this, and distributions are already using this
>> option, so I prefer not to make changes here.
>
> I'm sorry to remind you something you know pretty well - the traditional
> recommendations on choosing --enable-FEATURE[=ARG]/--disable-FEATURE[1]
> vs --with-PACKAGE[=ARG]/--without-PACKAGE[2].
>
> The first pair of options is to specify which build-time features to
> enable, and the second one is to specify which external software to use.
>
> If a downstream does not follow the documentation, this fact shouldn't be
> normally used as a rationale for not following the documentation upstream.
>
> If changes are accepted upstream as is just because they are already in
> use downstream, this would open the way to all kinds of sloppy changes.

I think your comment is based on an assumption that this is a new
option?

This change did not add the --with-default-link configure option, only
the documentation for it, and it changed the default to the safe one.

Thanks,
Florian