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

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

On Fri, Apr 29, 2022 at 06:14:27PM +0200, Florian Weimer wrote:
> * 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?

Yes, the suggestion of new option --disable-custom-link somehow made me
think that --with-default-link is also a new option name, not something
that goes back to 2011.


-- 
ldv