From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from vmicros1.altlinux.org (vmicros1.altlinux.org [194.107.17.57]) by sourceware.org (Postfix) with ESMTP id B44EC3858C2C for ; Fri, 29 Apr 2022 20:48:45 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org B44EC3858C2C Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=altlinux.org Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=altlinux.org Received: from mua.local.altlinux.org (mua.local.altlinux.org [192.168.1.14]) by vmicros1.altlinux.org (Postfix) with ESMTP id 1979B72C8DC; Fri, 29 Apr 2022 23:48:45 +0300 (MSK) Received: by mua.local.altlinux.org (Postfix, from userid 508) id 0A87D7CE7DE; Fri, 29 Apr 2022 23:48:44 +0300 (MSK) Date: Fri, 29 Apr 2022 23:48:44 +0300 From: "Dmitry V. Levin" To: Florian Weimer Cc: Siddhesh Poyarekar , libc-alpha@sourceware.org Subject: Re: [PATCH v3 2/2] Default to --with-default-link=no (bug 25812) Message-ID: <20220429204844.GA11314@altlinux.org> References: <15c7f6e9afe2c2b9c51ebc6372682a39b0932712.1649691083.git.fweimer@redhat.com> <87a6cdtykm.fsf@oldenburg.str.redhat.com> <20220429160206.GA7698@altlinux.org> <871qxf27fg.fsf@oldenburg.str.redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <871qxf27fg.fsf@oldenburg.str.redhat.com> X-Spam-Status: No, score=-12.5 required=5.0 tests=BAYES_00, GIT_PATCH_0, KAM_DMARC_STATUS, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=ham autolearn_force=no version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on server2.sourceware.org X-BeenThere: libc-alpha@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Libc-alpha mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Apr 2022 20:48:47 -0000 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