From owner-svn-src-all@FreeBSD.ORG Sat Nov 8 22:24:53 2014 Return-Path: Delivered-To: svn-src-all@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 3B72B127; Sat, 8 Nov 2014 22:24:53 +0000 (UTC) Received: from mail-qg0-x22b.google.com (mail-qg0-x22b.google.com [IPv6:2607:f8b0:400d:c04::22b]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id E17CD3F3; Sat, 8 Nov 2014 22:24:52 +0000 (UTC) Received: by mail-qg0-f43.google.com with SMTP id f51so3978231qge.16 for ; Sat, 08 Nov 2014 14:24:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:from:to:cc:subject:message-id:in-reply-to:references :mime-version:content-type; bh=MA/vSEmZvNo+qE7Qqui808CDSGUTOQhk/aFHirJFacg=; b=AtlL6G9I+hfD8UeZdnkfOZvfhDdW4TKM1h3VrgghtOK9pm8BRY0KxLumWGKcz8MWVt vAKChyTku6J1SitEMSvttpfQaIG7l7BkOtA93Pva8ViKIDGwDmMzgRsHGXTsAdPd3SQo tG+BGDndJWE293liUKpTz1xZeuU+uSAA32kwesDxqsNBNYC4nhrn8iEcyOY0kc2SWgZs T4ElXtCG+KUSjG38AsM2quNOw4J0D/PcJQaIh9s3NaSEQtkOZehAo64nYl1dPMo9hk0I o8mewaobyp5M70aBigC0a49OlDBMKLvDa92i3UYJrcVuZfflIKWJUrge848UqXINXTs1 AMvA== X-Received: by 10.140.106.34 with SMTP id d31mr19813003qgf.39.1415485492169; Sat, 08 Nov 2014 14:24:52 -0800 (PST) Received: from kan ([2601:6:6780:780:226:18ff:fe00:232e]) by mx.google.com with ESMTPSA id u8sm11744913qat.27.2014.11.08.14.24.51 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 08 Nov 2014 14:24:51 -0800 (PST) Date: Sat, 8 Nov 2014 17:24:40 -0500 From: Alexander Kabaev To: Andriy Gapon Subject: Re: svn commit: r274200 - head/share/mk Message-ID: <20141108172440.12418020@kan> In-Reply-To: <545E7882.90209@FreeBSD.org> References: <201411062246.sA6MkeLN018716@svn.freebsd.org> <20141108120000.3f16feab@kan> <545E7882.90209@FreeBSD.org> X-Mailer: Claws Mail 3.11.1 (GTK+ 2.24.22; amd64-portbld-freebsd11.0) MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; boundary="Sig_/LTlB.owL03b7LY1S/P6I9UB"; protocol="application/pgp-signature" Cc: svn-src-head@FreeBSD.org, svn-src-all@FreeBSD.org, Mark Johnston , src-committers@FreeBSD.org X-BeenThere: svn-src-all@freebsd.org X-Mailman-Version: 2.1.18-1 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: Sat, 08 Nov 2014 22:24:53 -0000 --Sig_/LTlB.owL03b7LY1S/P6I9UB Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable On Sat, 08 Nov 2014 22:09:38 +0200 Andriy Gapon wrote: > On 08/11/2014 19:00, Alexander Kabaev wrote: > > On Thu, 6 Nov 2014 22:46:40 +0000 (UTC) Mark Johnston > > wrote: > >=20 > >> Author: markj Date: Thu Nov 6 22:46:40 2014 New Revision: 274200 > >> URL: https://svnweb.freebsd.org/changeset/base/274200 > >>=20 > >> Log: Automatically build with debug symbols when building with > >> WITH_CTF. Otherwise there's nothing for ctfconvert to do, and it > >> ends up emitting an error for each object file. Also remove some > >> redundant checks from bsd.prog.mk and bsd.lib.mk. > > > >>=20 > >> -.if ${MK_CTF} !=3D "no" && ${DEBUG_FLAGS:M-g} !=3D "" +.if > >> ${MK_CTF} !=3D "no" CTFFLAGS+=3D -g .endif .else > >=20 > > I have a question about this and another similar change. Does it > > have the effect of always leaving binaries with debug symbols in id > > WITH_CTF is in effect and do we now rely solely on install > > stripping binaries at later stage to get rid of the debug symbols? > > IMHO, we should only pass -g to ctfconvert if WITH_CTF is set _and_ > > user requested debug symbols explicitly. Your change seems to be > > breaking that. >=20 > Hmm, I do not follow your logic here, sorry. > So, you say that stripping should be ctfconvert's job? Why? >=20 > --=20 > Andriy Gapon Because when building stuff with unwanted debug symbols one should make sure they are really gone and the patch basically undoes than promise. Whose job is it to strip .o's that end up in as the part of the .a archives, for example? DEBUG_FLAGS are there for users to be able to specify, khm, own debug flags and stuffing values in there automatically is just wrong. Also, there are these bits in our .mk files which I did not remember were there: .if !defined(DEBUG_FLAGS) STRIP?=3D -s .endif So, when present, DEBUG_FLAGS do prevent the stripping of binaries completely, making the patch as is even more wrong that I thought originally. --=20 Alexander Kabaev --Sig_/LTlB.owL03b7LY1S/P6I9UB Content-Type: application/pgp-signature Content-Description: OpenPGP digital signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iD8DBQFUXpgyQ6z1jMm+XZYRAiU8AJ0e3GLmrB7W9eZM7aMyIxJfzfL/zgCeO1b9 6A3IN9jzQoqlyMMmB5FWeuo= =JcDF -----END PGP SIGNATURE----- --Sig_/LTlB.owL03b7LY1S/P6I9UB--