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

["Dmitry V. Levin" <ldv@altlinux.org>]

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.

[1] https://www.gnu.org/software/autoconf/manual/autoconf-2.71/html_node/Package-Options.html
[2] https://www.gnu.org/software/autoconf/manual/autoconf-2.71/html_node/External-Software.html


-- 
ldv