From owner-svn-src-all@FreeBSD.ORG Sun Jun 8 18:45:01 2014 Return-Path: Delivered-To: svn-src-all@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 7E64BDE9; Sun, 8 Jun 2014 18:45:01 +0000 (UTC) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 049382E20; Sun, 8 Jun 2014 18:45:00 +0000 (UTC) Received: from tom.home (kostik@localhost [127.0.0.1]) by kib.kiev.ua (8.14.9/8.14.9) with ESMTP id s58IipEX065949; Sun, 8 Jun 2014 21:44:51 +0300 (EEST) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.8.3 kib.kiev.ua s58IipEX065949 Received: (from kostik@localhost) by tom.home (8.14.9/8.14.8/Submit) id s58IipX7065948; Sun, 8 Jun 2014 21:44:51 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Sun, 8 Jun 2014 21:44:51 +0300 From: Konstantin Belousov To: Alfred Perlstein Subject: Re: svn commit: r267233 - in head: . bin/rmail gnu/usr.bin/binutils/addr2line gnu/usr.bin/binutils/nm gnu/usr.bin/binutils/objcopy gnu/usr.bin/binutils/objdump gnu/usr.bin/binutils/readelf gnu/usr.bin/... Message-ID: <20140608184451.GZ3991@kib.kiev.ua> References: <201406081729.s58HTWkc006213@svn.freebsd.org> <74512A27-DD5F-4D43-BFA1-0AC04E0D08B4@FreeBSD.org> <20140608182728.GX3991@kib.kiev.ua> <5394ABD2.5040009@mu.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="S2CovAv8lqFB/Tem" Content-Disposition: inline In-Reply-To: <5394ABD2.5040009@mu.org> User-Agent: Mutt/1.5.23 (2014-03-12) X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no autolearn_force=no version=3.4.0 X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on tom.home Cc: svn-src-head@freebsd.org, svn-src-all@freebsd.org, src-committers@freebsd.org, Bryan Drewery X-BeenThere: svn-src-all@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: "SVN commit messages for the entire src tree \(except for " user" and " projects" \)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Jun 2014 18:45:01 -0000 --S2CovAv8lqFB/Tem Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sun, Jun 08, 2014 at 11:30:42AM -0700, Alfred Perlstein wrote: > On 6/8/14 11:27 AM, Konstantin Belousov wrote: > > On Sun, Jun 08, 2014 at 05:38:49PM +0000, Bjoern A. Zeeb wrote: > >> On 08 Jun 2014, at 17:29 , Bryan Drewery wrote: > >> > >>> Author: bdrewery > >>> Date: Sun Jun 8 17:29:31 2014 > >>> New Revision: 267233 > >>> URL: http://svnweb.freebsd.org/changeset/base/267233 > >>> > >>> Log: > >>> In preparation for ASLR [1] support add WITH_PIE to support buildin= g with -fPIE. > >>> > >>> This is currently an opt-in build flag. Once ASLR support is ready = and stable > >>> it should changed to opt-out and be enabled by default along with A= SLR. > >>> > >>> Each application Makefile uses opt-out to ensure that ASLR will be = enabled by > >>> default in new directories when the system is compiled with PIE/ASL= R. [2] > >>> > >>> Mark known build failures as NO_PIE for now. > >> No, no, no, no more NOs! > >> > >> I?ll leave it to others who understand the current build system in day= s when it?s not broken to fix this entire splattering across all these Make= files; we really need a better way for this. > > I have no words to express my dissatisfaction with this commit. > > If change to the build of _some_ usermode binaries require patching > > of loader', csu and rtld Makefiles, obviously it is done wrong. > > > > Why almost half of the binaries require opt-out ? > > > > PLEASE REVERT THIS. > Wait. Does this not serve as a useful stake in the ground for people to= =20 > come in and update things? Instead of asking to back out, shouldn't we= =20 > be doing an announcement "ok folks, it's now time to fix this!" and move= =20 > forward? Otherwise we may never get any pie. Let me reformulate. Somebody commits broken change, despite it was pointed out by many before the commit. From the changes it is obvious that people which proposed it do not understand what they hack on. And then, somebody else must run and 'fix' previously non-broken code. Sure, you get the pie. --S2CovAv8lqFB/Tem Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBAgAGBQJTlK8jAAoJEJDCuSvBvK1BpfsP/25JKsv8sycbc1LUys9n5eIW iThp5fE9468Une7DZr1KSnUPu0JQU7dm+hH7Tms6FrhgI29/NqRbAZx9I2RSKLHR FgoQ5cZX+ikuov5uGW0pGypLz4qTQPI7m8viSs5dLUS2CmcqyQhwu+4NYbj/DO73 cET6NmfjeuXwdZjU/bPX+b5Q7/aCCQRHnKtm7wou+W3WXOLgyGm5qlqM+j2/rnQt fSqj2M4dEiqDtX37lr0OIFbcCs+opcySbYhycFSrtwUNK5jVFlcIX1FODq/rMVwq GAxaxiB4EjMSCiBM+Er0A2KRmv8H6nyaDu3rny/8Nw6JsWkUs0tEyxQN2mGwEFtr YsEER60NEjHaXXcZJxkCQfLpdR8+VX66Zf9nKFwCiSJTYd5YEgMyBy3vspWt08ND CcFTG55ezNFNsAqdkHgJxAOCSrCBA8gxwzWhsOOtnkhMVoAMX4QYPSDT4dTQ3eOh rxowwl+hy9fKS5Rb/QBiNjDMFIBgzi4ZqWpAzmRMjh7/EkJr6nd4lHup9pHd/WNp sk3SeOaelXhHrQjToimYv7XV7cxTB51/QwBlByIYR8hpwmoCJFxeH9oRba2Px1cV rIzNkcz9ictlEOouYEno6bZ+MmR84Va7/Fga1cbFIwxPwAFoP4z3fMrY3x8h11xN fLKvZ86lxWFaaGjYmApn =8mU+ -----END PGP SIGNATURE----- --S2CovAv8lqFB/Tem--